Need to add additional Domain Logic to the "Order" Aggregate-Root

[CESARDELATORRE]

Need to add additional Domain Logic to this Aggregate-Root for scenarios related to Order state changes, stock availability validation, etc.

Current implementation of the Order Aggregate-Root is too simple in regards behavior.
Other than that, using DDD patterns makes no sense. An Order can have a lot more of complexity in Domain Logic..
Code:
https://github.com/dotnet/eShopOnContainers/blob/master/src/Services/Ordering/Ordering.Domain/Order.cs

The Order Aggregate-Root should have more sample domain logic, invariants and business rules validations so it makes sense to use the DDD Aggregate-Root pattern.

We actually just have the AddOrderItem(OrderItem item) method in here but with almost no domain logic or business validations.

I know that this is a simple example and not a real e-Commerce, but in this case, we need to show where to implement the business/domain logic --> in the Aggregate-Roots methods.

So, we need to add more domain logic here. It is actually too poor in regards domain logic.
For instance, you might get the same product item as multiple AddOrderItem(params) invocations. In this method, you could check that out and consolidate the same product items in a single OrderItem with several units (2, 3, 5, whatever the number of units), plus, if there are different amounts of discounts per prouct but the product Id is the same, you should apply the higher discount.., or any other domain logic to be applied.

Anyone reading this issue (Jimmy?), please, can you confirm the approach and suggest interesting domain rules/logic to add to the Order Aggregate-Root?

[iancooper]

An Aggregate Root is just a transactional boundary. The other name for an Aggregate Root is a Coarse Grained Lock (see Fowler PoEAA). The purpose of an Aggregate Root is mostly to avoid lock escalation and deadlocks - instead of locking the whole graph, you just lock the root, and you can't deadlock because you have to go through the root as a gatekeeper.

So to identify an Aggregate Root you need to understand your transactional boundaries i.e. what needs to be transactionally consistent, and what could be eventually consistent.

It's not uncommon for an Aggregate Root to be just one entity i.e. the transactional boundary only handles that one entity. This is still an Aggregate Root. The name is a little confusing, because we tend to assume that there MUST be an element of aggregation on a root, There COULD be, but there does not have to be.

The prohibition on only accessing an entity via an aggregate root i.e. repositories deal with aggregates is because you must lock.

If you need to lock the root, you have two options: (1) an intent lock i.e. when you get the entity from the Db, lock with intent to update (2) a pessimistic offline lock where you need to create a lock table etc.

My experience is that you only require (2) when the operation is long running and you want to give feedback in the event of a collision i.e. 'another user has this locked, please try later'.

To understand (2) you need to think about multi-user requirements. An order is unlikely to be multi-user, probably only one person will be updating it. You can just use an intent lock to protect the aggregate.

[CESARDELATORRE]

Right, I have a section in the Guide/Book explaining Aggregates and Aggregate Roots explaining very similar concepts (AR are also called Root Entity, originally named by Eric Evans, If I remember well).

However, the definition of an Aggregate is more a "consistency boundary" more than a transaction boundary. Usually it coincides, but you could have an aggregate consistent within itself while being part of a larger transaction. But, agreed, usually the way to identify/define aggregates should be based on the identified transaction needed by the business and to avoid lock escalation and deadlocks, therefore, it usually coincides.

I might update the Guide/eBook and mention the goal "to avoid lock escalation and deadlocks" which is important. Not sure if I did so..

In almost all of our use cases we won't need pessimistic offline locks. That won't scale well and usually is not needed in many cases. For sure, in this app, I don't think so. So, we're aligned on that.

It would be great if you could provide feedback about the section focusing on Aggregates in the Guide/ebook.
Thanks for your feeback! :)

[iancooper]

Will do, trying to catch up :-) (PS It is worth checking out Coarse Grained Lock in PoEAA if you have not for a while, as DDD Aggregates are called out there, and it gives another perspective)

[CESARDELATORRE]

:) That's book, from Martin Fowler is the oldest hard-cover technical books that I have, . ;) - That one, and Eric Evans' blue book are probably my preferred hard-cover books. Both are great, still applicable in most of the cases.
Note that I agree, transactions should normally drive the aggregate's definition.
It is also worth to read the articles from Vaughn Vernon on "Effective Aggregate Design" where transactions are the main driver. https://vaughnvernon.co/?p=838
I do highlight it in my guide/eBook, as well.
Agreed, but however, the Aggregate definition is a "consistency boundary", it could be consistent within a larger transaction, and sometimes you can make an exception and include more than one aggregate within the same transaction and it wouldn't be a crime. ;)
But yes, I'd say that in most of the cases one transaction should deal with a single aggregate..

[mvelosop]

Closed as it was included in the Roadmap (vNext).