Using the Domain Driven Design Bounded Context Concept to Shrink a Large Domain Model
Developers can apply the Bounded Context concept from Domain Driven Design (DDD) to divide a large model into smaller models using the Database Context (DbContext class) in Entity Framework (EF), Julie Lerman recently explained in MSDN Magazine.
Moving from a single model comprising many classes in one context to smaller models has benefits, according to Julie, a Microsoft MVP since 2003, working as a consultant and mentor on the .NET platform. Bounded Context creates smaller, more cohesive models with boundaries between models. Julie's article builds on this but notes that Bounded Context within DDD is a larger concept than using EF DbContext, and she therefore calls her implementation “Constrained” or “Focused” DbContexts.
By separating classes for different contexts, e.g. separating classes for customer care from classes for orders and shipping, and putting these classes into separate DbContexts, Julie splits a large context, containing all classes in an application into smaller and more focused contexts. This retains the same large underlying data model and database tables.
When not all attributes of a class are needed within a context, a smaller, more focused class can be created that covers parts of the original classes and indirectly of the underlying database tables. This is done by using views into the database. A restriction on these classes is that they cannot be used for inserts into the database if there are non-nullable columns not under the control of the class. The DbContext will throw an exception in response to such an insert.
Setting up the database with automatic creation of all tables, “Code First”, requires extra work with a separate “über-model” and a DbContext containing all classes. This complete context is then used for initialising the database.
Eric Evans, author of the original DDD book, reacted positively in a tweet but others have some concerns about applying a Bounded Context in this way and offer alternatives. One reaction is that this violates the concept, citing the DDD community definition:
“Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don't be distracted or confused by issues outside.”
Entity Framework is Microsoft's object-relational mapper for the .NET platform.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015