![]() With your hands on its instance, you find yourself in the centre of the universe of your domain objects, where you can crawl from one entity to another. Very often it is found to be handy to have all the entities accessible from a single context. ![]() And then this DbContext gets injected as a dependency to your domain code e.g. ![]() What starts as a just few domain entities, soon turns into a tightly coupled web of entities in a fast-growing monolith.Ĭentre of the universe: Most of the monoliths have a single DbContext containing almost every entity in your application. The ease at which we can introduce “yet another entity” in our DbContext (and database), tempts us to neglect the fact that this new entity may belong to a different aggregate root or bounded context. While we live in the illusion of being in control, the situation slips out of our hand faster then we realise. Walk in the park: ORM is a facility, whose comfort makes us lazy. To begin with I would like to highlight some of the traps of using an ORM: For simplicity, I will refer to it as DbContext in this post. It acts as a conduit between your code and database. In a typical ORM based N-Tier application, your data tier is replaced by a superclass called DbContext in Entity Framework and Session in NHibernate. If you are not familiar with DDD concepts, I would encourage you to read Eric Evan’s book.Įntity Framework (EF) or any other ORM has almost become a de facto tool to implement the Repository pattern, mainly because it makes the implementation significantly easier. So starting with a monolith and keep pruning / shaping the code as it gets bigger, will be a good strategy to employ. Creating bounded context without understanding the domain runs a risk of getting incorrect boundaries, which would be more expensive to fix. Often what starts as an ideal view of the DDD world applying OOP principles, soon turns into a tightly coupled monolith. Even if it is realised, the high costs of refactoring discourage to bring things back on track. The cost of refactoring gets higher with time as unchecked coupling gradually spreads to all the tiers, especially the database. ![]() Not many applications manage to maintain the clear boundaries between bounded contexts as they grow bigger. Domain Driven Design (DDD) is the widely accepted and proven pattern to build applications dealing with complex domains. ![]()
0 Comments
Leave a Reply. |