Domain-Driven Design – Understanding Bounded Contexts and Domains

Architecturedomain-driven-designenterprise-architecture

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).

Best Answer

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.

Related Topic