Use This Pattern To Design a Rich Domain Model With DDD

[@MilanJovanovicTech]

Want to master Clean Architecture? Go here: bit.ly/3PupkOJ Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt

[@DylinMaust]

Not really seeing the value here.. The aggregate should have all line items in memory and can check the item count without any repository usage, right?

[@nikogj9495]

Agreed, there is a discrepancy in the RemoveLineItem where the Order checks for line item count using the repository, and also gather one its lines using its private field _lineItems. This induces implicit coupling where the Order knows not all of its lines have been loaded, eg it depends on how the persistence layer is working

[@marna_li]

Agreed. I would have picked another example. But the point is that the behavior on the Domain Object is calling out some other "Service" in the Domain. Usually an interface that could be implemented elsewehere.

[@MB-Kajtech]

Have to disagree a bit. One of the cases I've run into is having an invoice with thousands of lines so loading them all into memory and querying them from the database just for removing one line is a significant enough performace drain. Of course this won't happen with a consumer type order with maybe tens of lines but when the invoice/order is for a company or a department where each line represents a service the line count gets very high fast. I do agree that not eagerly loading line items which are obviously a part of the domain model is a Persistence Ignorance violation, since I'm doing them for performance, but well as in everything there are trade offs.

[@Ogix7]

​@@MB-KajtechIn that case I would pass line item count to the domain method instead of the whole repository. Testing the method would be much easier.

[@DieDona]

​@@Ogix7 but then wouldn't it be easier to get a bad code? How to make it clear that you need to check it against a repo? I'm thinking if this should be wrapped inside a domain service with repo injected into the ctor

[@arunnair7584]

As a rule of thumb, we should try to avoid the use of Repositories from inside Aggregates, if at all possible. - Vernon, Vaughn (2013-02-06). Implementing Domain-Driven Design

[@MilanJovanovicTech]

I went to that quote in the back, but couldn't really figure out the "why" behind the statement in the given context. Why do you think he said that?

[@arunnair7584]

​@@MilanJovanovicTechAggregates shouldn't have direct access to repositories in domain-driven design (DDD). An aggregate should not be aware of how its data is stored or accessed because its role is to enforce the business rules of a specific limited environment. Instead, a domain service or application service should be used by the aggregate to interact with the repository. Basically separate business logic from persistence concerns. Even there you can use an observer to decouple the Aggregate from any repository or any other class. You can do this via an EventBus (risk single point of failure).

[@ThugLifeModafocah]

@@arunnair7584 On another point of view, the repo being an interface in the domain exists exactly for this purpose. To remove the awareness from the domain about data persistence. In the blue book, Evans says that a repo should be considered by the domain as just another object collection, without any knowledge of its internals, it is a in memory list, a file, a DB, whatever... It would behave as a normal collection. The red book has a good aproach for the problem, since the blue book has "never" dictated a straight rule for the implementation details (kind of). Then VV comes with a straight path the we could understand and that creates a clear solution separating things. BUT, in my opinion, it is not exactly what Eric Evans meant in his writings. Otherwise, why would we have the repo interface in the domain if the domain will not use it? To use it only in domain services doesn't seems a good explanation.

[@RadixSort3]

@@arunnair7584 Aggregate shouldn't know repository implementation. The repository interfaces are defined in domain (as oppose to application). The main reason is when needed Domain layer should be able to use repository interface.

[@arunnair7584]

@@RadixSort3 That's a fair point. But I prefer observer interface, since I have using this even bofore DDD.

[@pablolopezponce]

You are already performing a join in the database to get the line you need, even if you are only hydrating one line, and then you need an aditional query to do the count. I'm not sure this is more performant than just loading all the lines in memory. Also, passing the IRepository as a parameter to a domain method smells bad to me.

[@DieDona]

Recently I deliberately choose not to pass a repo inside my domain method, but I could not sustain exactly why. It gets harder to test, but is it really bad?

[@MilanJovanovicTech]

I don't see it as a smell, because I think of the repository as part of the Domain model. The other argument stands - I should've picked a better example.

[@thomasjespersen]

I normally like your videos. If your argument is performance, and you are willing to make compromises and hacks like this, it would be much cleaner to use a stored procedure or custom SQL. You are doing 3 round trips (1. Fetch Order with one order line, 2. Check order line count, 3. Save changes), so performance is clearly not your concern. Personally, I would always fetch the entire aggregate before updating it and enforcing logic in the domain using POCO. It should be very rare you would need to do these kinds of performance optimizations.

[@MilanJovanovicTech]

Thanks Thomas, appreciate your feedback. I should've used a better example for what I was trying to explain in this video.

[@pazzuto]

This is normally what I do, retrieve the complete aggregate and apply rules and save it back as a whole. I'm surprised Milan showed this example this way and didn't touch on CAP that explains these options better.

[@cwevers]

Can't you just check the amount of line items of the order aggregate, without additional roundtrip to the DB?

[@marna_li]

Exactly. The aggregate should be consistent at all times. But perhaps there is a case when it is not a true aggregate. Like when the orders are big - having many items that might change during this operation.

[@GiovanniCostagliola]

@@marna_li Aggregates MUST be always manipulated in their entirety otherwise you're opening the door to the hell: imagine two concurrent transactions that operate on a slice of the items each… bye bye integrity… bye bye DDD…

[@MilanJovanovicTech]

I was trying to illustrate what Marina is saying, but it obviously should've been presented better. Will do better!

[@stefan-d.grigorescu]

​@@MilanJovanovicTech Why does the Order aggregate contain the line items entity if not to enforce such business rule by itself? After repo loaded the aggregate root with all its dependent entities, the aggregate should have everything it needs already. If not intending to load all the line items with this aggregate root (maybe due to their large number), probably they would need to be extracted into a new separate LineItem aggregate. This would add complexity to enforce the line items business rules though.

[@xskyaflake]

Why would the Domain know what the (definition of the) Repository would look like? This seems like introducing another problem for an existing problem. Not much added value.

[@marna_li]

That is where a lot of people have different opinions on whether the repository is known by the domain or not. But depending on your case, your domain services might be using a repository.

[@MilanJovanovicTech]

If you consider your repository part of your Domain model - which is what I'm doing here

[@andreibicu5592]

I also do not like having repositories part of the Domain model. It's a coupling I do not need. In this case, Milan could have just provided to domain a boolean hasMoreLineItems, or a number lineItemsCount, and the initial problem would have been solved without additional dependencies.

[@johannormen]

The idea with Repositories is to act like a Black Box for the domain Entries not to be used within them, it's not fully an antipattern but as close you can get. The problem is related to cohesion and coupling. You do want to have high cohesion within your entities, and as much low coupling as you can. In this case you force the entity to know about it's own back box component, the repository, and make it depended to that one. And in that case you increase the Orders domain cohesion, and also make it dependent on a layer it should not really know exist the repo, and make it more coupled with the underlayer. A better way is to get the order and just ask the order domain line items if any, or you can add a Validation to the command, to verify if you are shall / can perform, the command at all. It's easy to see if the coupling and cohesion is a problem by start with Unit tests. It will direct tell you that you need to mock a repository to get your domain to handle it's a business' rule when a domain shall be designed to handle it's own states and just that. There is also more long lived problem to this approach. Even if I do not like the idea to split up a solution with separate projects, but if you should go the whole way and add the repo in a project too you will directly see the dependency problems. Repo shall have dependency to the domain. But the domain can't have dependencies to the repos. It will make it circular. And that's also a part of separation of concerns. Even if you but repo in the same project as the domain, we shall always consider references and try to avoid circular.

[@MilanJovanovicTech]

It's a tradeoff of purity vs completeness vs performance. This optimizes for completeness and purity. Doing the check in handler would be purity and performance, without the completeness.

[@johannormen]

@@MilanJovanovicTech This is not purity. It's bad complexity. You just make a domain to have dependencies to a layer that are used to actually retrieve the state. If you also add a unit test to it you will see the unit test will be more complex as well. And that is an indication too. It's software so we are allowed to do what ever we want :D but still as a rule of thumb, we should try to avoid the use of Repositories from inside Aggregates, if at all possible. Because it create low cohesion and high coupling. And that's what you do not want to have. And that's the main goal of good design. DDD is not really made for pure performance, mostly for design and maintainability. A nice and simplicity abstraction over the complex OOP/OOD. But you are free to do what ever you want. But be care full :D the complexity can grow...

[@niezebenmansour3736]

I used the same pattern in a project but i have more than one contract (IRepository), there is a contract for the validation and the math operation (IChecker and ICalculator for each domain aggregate), so thank you so mush Milan for this great Pattern

[@MilanJovanovicTech]

Maybe it would've made more sense to move the check into its own service

[@davemasters]

Hmm, there may be some situations where an aggregate has a huge number of child entities (not sure order lines is a good example of this) and this approach might be more practical for performance reasons, but in general my default is to always eagerly load all child entities enforce invariants "natively" without requiring dependencies. I do however employ basically the same approach for inter-aggregate rules, where I create a cohesive domain service method that verifies state of 1 or more other aggregates

[@MilanJovanovicTech]

Perhaps I didn't choose the ideal example for the concept I was trying to show

[@davemasters]

@@MilanJovanovicTech btw I really enjoy your videos. Always really well explained

[@lucasterable]

Takeaways from this video: principles and patterns are not the hard part. The hard part is coming up with fitting, convincing examples that would not elicit objections. ;)

[@MilanJovanovicTech]

+1 🚀

[@GiovanniCostagliola]

You're overloading the Repository pattern of concerns that aren't in its scope: repository should provide means to manage the persistence and fetching of aggregates respecting their integrity. Aggregates should be treated as an whole: you should rehydrate them in their entirety and then perform any operation over them. Your design is problematic and complex and doesn't scale very well. Domain services are the best place to orchestrate logic between repositories and aggregates. Avoid to pass repository to aggregates, your design will be more clean and maintainable. Imagine the case where two concurrent transactions operate on the same aggregate and your operations works on "slices" of it's full state… it'll be a nightmare to manage integrity and DDD's AggregateRoot tactical pattern is designed just to "simplify" the management of such a complexity… If you want play with DDD you have to recognize that there's a price to pay to achieve that elegance.

[@MilanJovanovicTech]

Should've used a better example here 😅

[@slobodanmikaric2180]

nice video, so as I can see IOrderRepository acts like Domain Service. If we separate Domain and Core, IOrderRepository interface will be defined in Domain project and implementation will be upper in Core layer.

[@MilanJovanovicTech]

Yes, kind of like a domain service. I maybe should've even moved it into a proper domain service since people got really upset by the idea of having a repository in the entity

[@tolgatoganduz]

Order is aggregate so all items should be read in repository to protect data and domain consistency. Also aggregates should not access repository and factory objects, it creates circular dependencies.

[@MilanJovanovicTech]

Well, I tried to show something interesting here. How much I succeeded is up for debate.

[@artemvolsh387]

Great video, like even before watching)

[@MilanJovanovicTech]

Thanks Artem :)

[@asierpaz9190]

I am trying to learn DDD and that domain logic (HasOneLineItem) inside the OrderRepository confuses me. Shouldn't repositories only return instances of the AR it represents?

[@JonnyItunes]

Never bring repositories into the domain model. This violates single responsibility. This also violates the architectural design patterns of DDD and Onion. Repos are part of the Infrastructure layer and live outside of the Domain layer. Repos deal with persistence and the domain deals with data state. Order is an aggregate root and should control the state of the LineItems. The Order.RemoveLineItem function should be checking its collection of line items for the count. There is no need to have the dbcontext make an additional trip to the db just for a count of line items. Hopefully this helps clear things up.

[@GiovanniCostagliola]

You're right.

[@MilanJovanovicTech]

Probably not the ideal video if you're still learning DDD. Even more experienced devs have a lot of issues with this approach. Nonetheless, I still think it's worth considering in some situations.

[@jodainemoore8300]

have you got a link to the project?

[@MilanJovanovicTech]

It's shared on Patreon

[@jodainemoore8300]

@@MilanJovanovicTech Am not familiar with Patreon is it on Git hub ?

[@ThugLifeModafocah]

First time I see the repository being used in the domain layer (as I believe it should, because Eric Evans says that a repo should be considered by the domain as another regular domain object). Very cool. But I would go 2 steps further. I would pass the order repo and unit of work to the order too. Why? Because my handler would have 2 lines (orders is the repo 'just' a collection for the domain): var order = new Order(request.OrderId, orders, unitOfWork); order.RemoveLineItemHavingThis(request.LineItemId); The order variable would never be null. The constructor would be the responsible to retrieve the order from using the repo. If no order found, the constructor would return a valid object that internally just doesnt execute any of its methods (this is the same as having the order == null then return, but encapsulated in the order itself). If the order is found, then the remove method uses the repo and the unit of work to execute its jobs. The UoW is a domain interface also, like the repo. If know the end result of methods is important, I could add a internal 'logger' to register the calls and returns its outcomes like: var order = new Order(request.OrderId, orders, unitOfWork); order.RemoveLineItemHavingThis(request.LineItemId); order.DoAnotherReallyCoolStuffWithThis(request.Param); return order.ExecutedEvents(); If order was not found, the executedEvents would return, for example, an IEnumerable containing: ["Order item XPTO could not be removed because the order ABC was not found", "This another really cool stuff was not executed because the order ABC was not found"]; Than, the handler is just an dumb orchestrator. All the rules, the logic etc are encapsulated in the domain objects. Obs.: The spreaded way of a repo usage has zero relevance if the repo interface is from domain or application. It, in fact, make much more sense to let it in the application. It is very rare cases where you can find someone using a repo inside domain. It is always in handlers, in services, at application layer. So why bother to put it in domain? But with your approach in this video, then it makes sense. Then, I believe, is closer to what Eric Evans was saying in the blue book, IMHO, of course.

[@MilanJovanovicTech]

The point is you can use repos in domain services

[@ThugLifeModafocah]

@@MilanJovanovicTech Sure, but you can use it in domain objects too. Why not? Your example and mine shows how this can be done and that it is interesting and good to do so.

[@yeganehaym]

what if double check be double checks? i mean if you make a model for email and create method need to validation. you add a IEmailValidator to your create method but if we need more validations so we need to create more interfaces to check more validations. the method signature need to change every time and we need to fix references

[@MilanJovanovicTech]

Better simplify it

[@praveenupadhyay20]

Just to be sure if my understanding is correct. due to double dispatch pattern, we have passed repository to domain, and that's costed us for domain purity? am I right? I learnt, domain completeness, purity and performance in one of your video. here we achieved completeness, performance but not purity.

[@MilanJovanovicTech]

Exactly! You got it right :)

[@AhmedElAtari]

It looks weird a repository interface inside a domain aggregate. In my opinion, the domain layer should be agnostic about any persistence concerns.

[@MilanJovanovicTech]

That's a fair assumption. Except I don't see my repositories as persistence concerns, but part of the domain layer.

[@Downicon3]

Isn't this what use-case would we for, where would we want to remove line item again? Just "Remembering" seems to go into DRY too much and put repos into the Domain ?

[@MilanJovanovicTech]

I'm fine with repos in domain - since I only use them for working with Domain entities

[@nitrovent]

What would you recommend for a duplicate check, say e.g. for email address, when creating an aggregate?

[@nitrovent]

@@magashkinson gonna try that how it feels and if our framework supports it. what I don't like about the approach is the bidirectional dependency between entity and repository.

[@MilanJovanovicTech]

I actually made an in-depth video with possible options: kzbin.info/www/bejne/m3SaeIB9frdnfdk

[@chanep1]

Besides the fact that the order aggregate seems to have already all the items, there is a weird dependency in Order with the OrderRepository and also now an Order method does a sync DB call??

[@MilanJovanovicTech]

What's the difference if the DB call is made at the application level? It's still part of the overall api request/transaction

[@chanep1]

yes, that was usual in Active Record kind of Entity but with Repositories Entities don't do I/O usually. Also it mixes sync with async I/OI think. Also I was confused by the "double dispach" that I think is the kind of thing you want to achieve in Visitor patern when you call visitor.visit(this) but here there is only one Entity: Order and its corresponding 1 repository: OrderRepository, why that is called double dispatch? Anyway, your channel is very good, I just didn't understand this particular pattern

[@piotrc966]

why not _lineItem.count()==1 in RemoveLineItem instead injecting OrderRepository nad calling HasOneLineItem?

[@MilanJovanovicTech]

I was trying to showcase something else

[@pawegolik1209]

In this situation, we loaded just one line item with the specific lineItemId to improve performance (e.g., an order can have a lot of complex line items). So simply checking '_lineItems.Count' won't give an accurate count of all line items within the aggregate, as others may exist but were not loaded in this particular instance. However, when performing a full load of an aggregate (as we should do in most cases, right?) your way is better ;)

[@SuperJB1981]

Passing in the OrderRepository as a param to another class / method is a bit of a code smell. You could just create some sort of composite class that handles the aggregate logic and inject that into your handler instead of the repository. Repository would only be needed in that new class

[@MilanJovanovicTech]

Nothing really changes in the handling of the command. Just things moving places. But logic is better encapsulated in the Domain with this approach.

[@kennedydre8074]

Hi Milan, could you please provide the example code, reading it would help understand it deeper & better.

[@MilanJovanovicTech]

Sure

[@kennedydre8074]

@@MilanJovanovicTech Thank you so much. That would be so helpful.

[@MilanJovanovicTech]

@@kennedydre8074 I'll need a few days to get around to doing that. Shoot me an email if you want it quicker.

[@nayanc4353]

I'd have injected repository in ctor of order. 😊 I have to admit, this video felt like explaining a pattern which is just about putting checks in right place. Isn't this normal approach? Why would one call it double dispatch?

[@MilanJovanovicTech]

The Order doesn't really need the repository for all actions. So it makes more sense to use it in the method.

[@JonnyItunes]

This seems like very bad practice to allow repos in your domain models, which means that you are referencing your infrastructure in your domain. This violates single responsibility. Repositories handle persistence and domain models handle state. If Order is an aggregate root, let the order look at its line items. In the remove line item function in the Order model, you check to see if there is only one line item left in the collection and if so, then do not remove it. You obviously already have the line items collection populated. Why make an unnecessary call to a repository when you already have the data you need?

[@MilanJovanovicTech]

Not if you think about repositories as part of your Domain model, which I'm doing here.

[@oucemaz]

The domain model depending on a repository breaks the Single responsibility principle.

[@MilanJovanovicTech]

How?

[@oucemaz]

​@@MilanJovanovicTech From DDD perspective Domain model should be very centric and heaped with functionality. Domain model adding query logic, in addition to whatever else it's doing, violates the single responsibility principle. In this case IMO here you can leverage the specification pattern. How ? 1- You create a specification for GetByIdWithLineItem 2- You create a specification for HasOneLineItem 3- You combine both specifications with AND In RemoveLineItemCommandHandler all you have to do is call your repository with the combined specification. This is my way to go for such a scenario.

[@rapha5210]

You lose the purity of the domain, i prefer to lose the completeness.. the domain is enough complex to overhead it with calls to infrastructure, that could be done from application...

[@MilanJovanovicTech]

I like sacrificing purity, since I find it makes more sense

[@mohamedhosman]

If this is a domain rule, why not do this in the domain service or the domain model and not in the infrastructure

[@MilanJovanovicTech]

How is it in the Infrastructure?

[@tiagosantos2136]

Some issues in this video: - Repository for a Entity - Repository inside a entity 😢

[@MilanJovanovicTech]

Uh oh, what do we do now?

[@tiagosantos2136]

@@MilanJovanovicTech get order with ALL line items, remove the line item

[@MAUIMS-m4g]

that's how to create a problem to look for a solution.

[@MilanJovanovicTech]

You bet

[@amrsaid3599]

hi milan it's domain purity concept

[@MilanJovanovicTech]

Talked about that here: kzbin.info/www/bejne/m3SaeIB9frdnfdk

[@williamforsyth6667]

I cannot get used to this wasteful source formatting style. Dedicating 5 lines of the precious vertical space just for a null check and return!

[@MilanJovanovicTech]

It's mostly because I have to think about how the code will look in the video. So vertical is easier to read than horizontal.

[@williamforsyth6667]

@@MilanJovanovicTech The video is a good point I did not think of. However, this is mostly the accepted format nowadays, which I find contra productive.

[@thecodeman_]

👏

[@MilanJovanovicTech]

🔥🔥