Domain Driven Design (DDD): Domain Model Granularity and Bounded Context

Question

Afternoon all

I am currently studying Domain Driven Design (DDD) and am having trouble grasping a fundemental concept.

Patterns Principles and Practices (Millett and Tune)

During my studies I have often come across the term Domain Model (DM) however it is commonly discussed with various levels of granularity.

1. In some cases its represented as a collection of artifacts (UML, sketches, photos) of various interconnected objects (Customer,Sale,Quotation,Invoice etc) which outline all the concepts within a single sub domain.

   Such that there is only one model for a single sub-domain

2. In other cases its represented as a single entity such as Product, whereby a sub-domain will consist of many different Domain Models.

With the above ambiguity I am struggling to understand what a Domain Model actually is and how such models can be put into a Bounded Context (BC)

Further to this, I have read Domain Models can be shared between different Bounded Context.

For example Employee is shared between the Payroll and HR Bounded Context

With this in mind,

1. would I create multiple Domain Models to represent a sub-domain ?
2. or just a single one ?
3. If the later, how would one share such large models between contexts ?

Please could someone shed light on this ambiguity and explain exactly what a Domain Model is and how granular it can be.

Much Appreciated

Daniel

Answer 1

Patterns Principles and Practices (Millett and Tune) is a very good book on DDD with lucid explanation.

Using Strategic Patterns of DDD, the application gets broken down into sub-domains; where each sub-domain represents a distinct part of the problem domain. Complex sub-domains can contain more than one model and one model can also span more than one sub-domain.

Therefore it is important to clearly define the boundary of the model to protect its integrity.This is achieved by binding a model to its specific context, known as a bounded context. You have a domain model for each bounded Context.

Domain Model represent the problem space and is arrived at based on the discussions between development and business teams. It is based on ubiquitous language and is represented using sketches and UML diagram. The same also gets reflected in your code model.

Further to this, I have read Domain Models can be shared between different Bounded Context.

For example Employee is shared between the Payroll and HR Bounded Context

With this in mind,

would I create multiple Domain Models to represent a sub-domain ? or just a single one ? If the later, how would one share such large models between contexts ?

This is a case of Shared Kernel pattern, where two bounded contexts are sharing a subset of the same domain logic. You will need to create 3 domain models, one each for Employee and HR and one for the shared model Employee

Answer 2

Make sure you review The Blue Book.

exactly what a Domain Model is ...

A domain model is

• a collection of data/state/information that a business cares about
• the rules that govern how that data can change

read Domain Models can be shared between different Bounded Context

maybe...

Employee is shared between the Payroll and HR Bounded Context

An important thing to include in your design: the ubiquitous language changes as you cross the boundary between one context and another. If Payroll and HR don't understand Employee the same way, with the same rules governing the changes to the data and the same life cycle, then insisting that they share the same model exposes you to risks that you wouldn't face if those models were kept separate.

Further complicating things is understanding whether your model is the "book of record". For instance, Employee -- if you are talking about the human being -- is out here in the real world. The real world is the book of record; the information you've captured in your databases is just a copy.

For example: in the real world, people are legally entitled to change their names. What does that mean to your business? Does the timing of that impact have the same implication on HR processes that it does on Payroll processes? If they are the same today, are you sure that will always be true?

Prior to being an Employee, the human being may have been an Applicant; does HR care? Does payroll?

There are also practical concerns -- if the HR database goes down, should that block payroll processing?