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?
404533 (5) [Avatar] Offline
That is indeed a very interesting design you have when pulling the events of an order "inside" that order. We hope we understand you right that what you get is a "limited event stream" that is scoped to the events that have touched that specific order.

As you say, audibility of the order becomes almost trivial - which is an important security aspect. And at the same time you get the other Event Sourcing benefits, such as being able to compute new "foldings" of the event stream.