I have used NHibernate for some time now but have recently started to reengage with Microsoft’s Entity Framework. I came across Julie Lerman’s course Entity Framework in the Enterprise on Pluralsight. This is an interesting course and deals with Repositories and the Unit of Work pattern, two concepts I have used extensively with NHibernate. But Julie also deals with a DDD concept – the Bounded Context. It’s been a while since I’ve dealt with DDD so I thought I’d spend some time re-familiarising myself the Bounded Context.
Firstly, let’s see what Eric Evans had to say about Bounded Contexts in his book, “Domain-Driven Design, Tackling Complexity in the Heart of Software”.
“Multiple models coexist on big projects, and this works fine in many cases. Different models apply in different contexts.” [1]
“Multiple models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand. Communication among team members becomes confused. It is often unclear in what context a model should not be applied.” [2]
“A model applies in a context. The context may be a certain part of the code, or the work of a particular team. For a model invented in a brainstorming session, the context could be limited to that particular conversation.” [2]
“A BOUNDED CONTEXT delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other CONTEXTS. Within that CONTEXT, work to keep the model logically unified, but do not worry about applicability outside those bounds. In other CONTEXTS, other models apply, with differences in terminology, in concepts and in rules, and in dialects of the UBIQUITOUS LANGUAGE. By drawing an explicit boundary, you can keep the model pure, and therefore potent, where it is applicable. At the same time, you avoid confusion when shifting your attention to other CONTEXTS. Integration across the boundaries necessarily will involve some translation, which you can analyze explicitly.” [3]
This makes perfect sense. You can see how the concept of a user, for example, would have different meanings to different departments within a business. If we tried to model a single user that has all the attributes required to satisfy all departments we might end up with a bloated and confused user entity. By separating the model into different bounded contexts, for different departments for example, and having the user defined separately within each context the result is more sharply focused and less confusing models.
The question that might remain is, how could we keep different bounded contexts synchronised? For example, if a user is created in one department in our hypothetical business application, how would we also create it in another at the same time? This could be accomplished using Domain Events or some kind of correlation ID for the same entity in different contexts.
See also
- Shrink EF Models with DDD Bounded Contexts, Julie Lerman
References
[1] Eric Evans, “Domain-Driven Design, Tackling Complexity in the Heart of Software”, ISBN 0-321-12521-5, p335.
[2] Eric Evans, “Domain-Driven Design, Tackling Complexity in the Heart of Software”, ISBN 0-321-12521-5, p336.
[3] Eric Evans, “Domain-Driven Design, Tackling Complexity in the Heart of Software”, ISBN 0-321-12521-5, p336-357.
