I'm trying to figure out how i approach DDD and the use of Bounded Contexts.
I've tried to come up with an example, to illustrate my question. (I'm using anemic classes for quickness).
I am trying to map out how I would go about separating domain objects within different bounded contexts.
I thought about the domain object that could be an Employee.
Let's say that I have two bounded contexts, the HR Department and the Finance Department.
Generally, the Finance department would require more information about the Employee than the HR Department. The HR Department wouldn't need any information relating to the Employee Bank Details, National Insurance Number or contracted hours. (Maybe in some businesses this isn't quite true, but lets just assume this in the example).
So in two separate contexts, the behavior/interaction required with an Employee is different.
HR 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; }
}
Finance 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 do i limit the Employee object in the HR Context, to only have the behavior it requires, and that the Finance Context has the Extended behavior.
If an application was broken up into multiple contexts, all with custom behavior associated to an Employee, how would I model the Employee object.
I have looked at different ways to build your Context map, and a shared Kernel seems promising, but it would mean that all contexts would then share all of the behavior associated to the Employee Domain object.
I would expect that each context would be limited.
Help!
Each BC defines its own model. Usually the Employee is a full defined concept only in one BC. Other BC have their very own definition of it and most of the time it will be an id (make it a GUID). In your example, the Employee makes sense to exist as a full entity only in HR. For Finance, you'll have an id and the fields that makes sense from the finance point of view. There is no duplication here, because the models serve different purposes (think of it as repeating alphabet letters to form up a word, every word is a combination of those repeated letters yet it represents a different concept).
Think of BC as independent components (projects, apps). Just because you have some fields in one, it doesn't mean you should re use that object in every app that might use those fields. Keep your models bounded and independent of each other. In time, chances are they will evolve in different ways.
Also, ask yourself if finance really needs the employee address or title or firstname/lastname. Your use cases will tell you what data you really need. Start with the concept name and model the use cases, this is how you find out the relevant properties and behaviours. And remember YAGNI , if there's no use case for it, then there's no object/field :D
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments