Domain Objects with Restricted Domain Content
I'm trying to figure out how I approach DDD and the use of bounded contexts.
I tried to come up with an example to illustrate my question. (I'm using anemic classes for a quick one).
I am trying to figure out how I will split domain objects in different bounded contexts.
I was thinking about a domain object that could be Employee.
Let's say I have two bounded contexts: Human Resources and Finance.
Generally, the Finance Department needs more information about the Employee than the Human Resources Department. The HR Department will not need any information regarding employee bank details, National Insurance numbers or reduced hours. (This may not be the case in some companies, but let's just assume that in an example.)
So, in two separate contexts, the behavior / interaction required with Employee is different.
Human Resources Department.
public class Employee
{
public int Id { get; set; }
public Title Title { get; set; }
public string Forename { get; set; }
public string Surname { get; set; }
public Address Address { get; set; }
public DateTime DateOfBrith { get; set; }
public DateTime EmploymentStartDate { get; set; }
}
Financial department.
public class Employee
{
public int Id { get; set; }
public Title Title { get; set; }
public string Forename { get; set; }
public string Surname { get; set; }
public Address Address { get; set; }
public DateTime DateOfBrith { get; set; }
public string NationalInsuranceNumber { get; set; }
public BankAccount BankAccountDetails { get; set; }
public double ContractedHours { get; set; }
}
Given this example, how to restrict the Employee object in HR content only to do the required behavior and that the financial context has extended behavior.
If the application was split into multiple contexts, all with custom behavior related to Employee, how would I model the Employee object.
I've looked at various ways to construct your context map, and a shared core seems promising, but that would mean that all contexts would then share all behavior associated with the Employee Domain object.
I would expect every context to be bounded.
Help!
source to share
Each bookmaker defines its own model. Usually Employee is a fully defined concept in only one BC. Other BCs have their own definition, and most of the time it will be id (make it a GUID). In your example, Employee only makes sense to exist as a complete entity in HR. For finance, you will have an ID and fields that make sense financially. There is no duplication here because the patterns serve different purposes (think about this by repeating letters of the alphabet to form a word, each word is a combination of these repeated letters, but it represents a different concept).
Think of BC as independent components (projects, applications). Just because you have multiple fields in one does not mean you have to use that object in every application that can use those fields. Keep your models limited and independent from each other. Over time, they are likely to evolve in different ways.
Also, ask yourself if finance really needs an address or employee name or first / last name. Your use cases will tell you what data you really need. Start with the name of the concept and model the use cases so you learn about the properties and behaviors involved. And remember YAGNI, if there is no point in using it, then there is no object / field: D
source to share
I have only limited knowledge of your domain, but I would probably model Employee
separately in each bounded context, i.e. had 2 separate objects so that they could evolve separately to fit each need of the context.
HR will oversee the use of new hires, changes to their details (name changes, etc.), as well as less pressing tasks like shooting and firing employees. So I would be tempted to keep key employee records in the HR system and when there is an update that needs to be aware of finance, I would push those changes to another system via a web service or message bus, etc. Creating properties, such as Title
, Forename
, Surname
, Address
and DateOfBirth
read-only in a financial context.
source to share