CRUD part of app in DDD\ES\CQRS

Question

I would like to use DDD\CQRS\ES in my project. I just started using it so I don’t have a lot of experience. I am aware of existing core domain, supporting domain and CRUD domain. My core domain have references to CRUD data. For example There are a lot of business rules in Order, but it contain basic information about Delivering Company, receiving point etc.

These informations are managed by admin. In my opinion I should use crud approach but what happen when I need to rollback events?

System is going to store mix of data – restored from event source and actual from crud part of app. I will end up with inconsistent data. For example, The order may be maintained by not existing company ( That company was deleted by admin when their have delivered package, but after rollback order is still active) In every project is part of CRUD data so how do you deal with this problem? Should I store company events?

Additionally, When I’m adding new order I should send company name and id via event because when Im rebuilding my ReadStore , there may not be company in database so I can’t get companyName from repository

PS. Do you know any CRUD framework to handle with simples CRUD operations?

PS.2 Do you know any example opensource project which containt CRUD part of app in ES\CQRS approach?

---

Ok. Maybe I described it too complicated. I just want to know:

• how to implement the simplest part of application ( poor business logic - mainly CRUD operations) when I store my core domain in event store and I would like to be able to revert previous state of my core domain

• Should I store crud operation in event store too or not?

• How provide data consistent after rollback event store?

• Which CRUD framework do you recommend for Java applications?

Answer 1

I think this is a common problem when dealing with DDD and especially when dealing with ES. This might sound simple but what you need to look for are the bounded contexts in your domain. Turns out that this bounded contexts map very well onto the services from SOA. Now when you get to SOA you realise that not all the services ( service as the S in SOA not as in web/windows service ) need to be implemented the same.

In my experience you are always going to have some services dealing mostly with CRUD operations and very little business logic, usually consumed by apps that are used by admins/special users. This services can and should be implemented with the least effort possible, without CQRS and ES and without over complicating them. Just make sure they publish relevant messages when something happens.

I strongly recommend Eric Evans - what i've learned about DDD since the book video.

Also Udi Dahan has some very very good videos about SOA and what SOA means: Avoid a failed SOA and Udi on SOA

I realise this is not actually answering all the details of your question, but i hope it will point you in the right direction.