442169 (1) [Avatar] Offline
I have read the chapter 7 and I found it interesting.
I think it can be summarize as:
- Make what you can be immutable, immutable
- Tell, Don't Ask
- Use Read-Only Entity, update it through a service
- Reduce complexity of states by splitting in smaller groups

The idea of CQRS is suggested in this chapter.
What about updating state with events as in a CQRS system (with benefits and drawbacks)?

Let's imagine an Order. Adding a new item would be:
val order = Order(orderId = 3)
val orderWithOneItem = order.add(OrderLine(product, Quantity(1))) 
// New instance created 
// return order.copy(items = items.add(orderLine))

So, orderWithOneItem will contain a new event call OrderLineAdded.
We can find the final number of order lines by aggregating the events.

Here, the advantages compare to a function addOrderItem are
- to allow auditing. I would be able to understand how I reach some state by looking at the events.
- to make testing easier. Order is immutable.
- we can still build a read-only snapshot
- to represent the business in a really expressive way

It's true what we have all drawbacks from CQRS:
- states as to be kept and/or snapshot updated often to get good performances
- what if events change?

What do you think of this approach?