Yvan P. (2) [Avatar] Offline
#1
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?
Dan Bergh Johnsson (6) [Avatar] Offline
#2
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.
588414 (1) [Avatar] Offline
#3
Just a random person passing by and saw your comment. In regards to performance and snapshotting that is almost never an issue. Snapshotting is trivial to do.


442169 wrote: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?