DDD Bounded Contexts & Domains?

Question

I've been working in a relatively complex application with 10's of database tables (Aggregates, Entities/Value Objects) and applying DDD. At this point it appears to be basically DDD-Lite meaning that there are Application/Domain Services, the Domain Model (Entities, Value Objects), and Repositories.

I picked up a book Implementing DDD and the first thing he is mentioning is DDD-Lite and Bounded Contexts and Domain Events missing as first mistakes which are usual when beginning DDD.

Currently I've tried organizing the Domain Model by Aggregate relationships, and using namespaces to demonstrate it.

I'm failing to see the benefit/downfalls relating to separating the Domain Model project into separate Bounded contexts (yet). Perhaps it will become apparent later on but I'd like some real life feedback on Bounded Contexts (and possibly sub domains etc. if they tie into it).

Answer 1

Consider a company that has a few different departments:

• Software Development
• HR
• Accounting

Can you come up with a user model that can expressively represent all those areas of business? Think of what the User entity could look like in each one. Perhaps it's split into three different entities:

• Developer
• Employee
• Payee

The effort to instantiate a user in each context is considerably different. Perhaps it's something like this:

• new Employee(ssn, name, joindate, dateofbirth, gender)
• new Developer(Employee, workstation, credentials)
• new Payee(Employee, role)

excuse the example, it's hard to illustrate accurately without a proper domain model to reference

If you used a naive implementation and used a single user entity, it would end up being an anaemic data model full of getters and setters, because you couldn't fully represent the user all over the place.

There are clear boundaries in the business, so it's useful to model them that way. A user logging in versus a user in a payroll system versus a user playing a game are all very different, even if they are part of the same grand system.

Thinking in another way - you can now create your developer management code to be very lightweight and independent from the rest of your system. It can use more accurate types with less baggage to worry about. It's the step to building smaller subsystems that may eventually be extracted out into its own application.

Answer 2

I can give you another example. Consider you have some ecommerce system. You would have products there, however products will be part of at least two different domains:

• Product catalog, where you keep your product description and all attributes
• Inventory, where you have product stock level

If you have one bounded context for both domains, your solution can quickly become a big ball of mud because you will start cross referencing it. At the end you will not have two domains anymore. Your product inventory will be spoiled with product catalog references and vice versa. As the result of this you will not be able to change one domain without touching another even you fully realize this is not required. Your models become dependant on each other and tightly coupled, and dependant in a bad way - being dependant on implementation.

If you, however, have two bounded context, all changes you do in one domain will not affect the other as soon as you keep your communication channels clear. It will mean you need to have data duplication but this is the least cost to pay for losely coupled component based application. Your domains can talk to each other using domain events. Even if you do not plan to have SOA based application in the beginning you will be able to scale up to that level when you need with relatively low effort since you just change the transport for your domain events, leaving the idea behind it intact.

Update: There is a good skillscast on SkillsMatter, from Eric Evans. He gives an analogy of the old story, when several blind man describe an elephant from their perspective. Since each man can only touch a part of the elephant, they describe it as a "tree", "wall", "snake", "rope". And each of those man is right within their context. Bounded context is where ubiquitous language lives. Outside the context, these terms might have completely different meaning but inside the context, the language is the same across multiple domains. Greg Young strongly suggests to start reading the blue book from chapter 11, since the most important, fundamental concepts are explained there. The focus on tactical patterns in the beginning of the book makes this "DDD-light" approach very common, when people stop reading somewhere around chapter 8 and miss the main things, that is somewhat buried at the second half.