在实际项目中确定领域驱动设计中的实体和值对象

Question

This is for the first time I am implementing the concept of Domain Driven Design in a real project. The project is about generating a permit for employees which would enable them to enter company premises. Through an Intranet site, an employee who already possesses an Employee ID, will be able to apply for a permit or apply for replacement of a permit, in case the permit is damaged or lost. And an administrator will process the applications and hand over a physical permit in the end.

I have a couple of entities - User , Permit and one Value Object - Employee .

• A User can be entirely identified by an Employee . Should I create a UserId as well? How do I handle the case in which the administrator may not only approve, but raise an application on behalf of an employee as well?
• The Value Object Employee has an Id property EmployeeId which I know goes against the principle of a Value Object. However, in my case, Employee is read-only. It doesn't matter to me if I get only the EmployeeId or the Employee as a whole. Am I doing this right?
• The Permit entity contains a lot of properties. How do I break down the properties of Permit into Value Objects?

public class User : Entity
{
    public Employee Employee { get; set; }
    public bool IsAdmin { get; set; }
}

public class Permit: Entity
{
    public int ApplicationId { get; set; }
    public string EmployeeId { get; set; }
    public string Type { get; set; }
    public string Status { get; set; }
    public DateTime RequestDate { get; set; }
    public DateTime IssuanceDate { get; set; }
    public string IssuanceReason { get; set; }
    public string SurrenderReason { get; set; }
}

public sealed class Employee : ValueObject<Employee>
{
    public string EmployeeId { get; private set; }
    public string Name { get; private set; }
    public string Department { get; private set; }
    public string Division { get; private set; }
    public string BirthDate { get; private set; }
    public string Designation { get; private set; }
    public string BloodGroup { get; private set; }
    public string SecurityLevel { get; private set; }
    public string EmploymentDate { get; private set; }
}

Apart from the concerns, I'd be grateful if someone could guide me to go about it in the most appropriate manner possible. Thanks.

Answer 1

You should create 3 entities

• Employee
• Permit
• User

Give it all an UniqueId --> because they are entity's so they are unique When there is a relation , for example between User and Employee, You can use a value object Employee (so 2 VO's)

Answer 2

From my point of perspective it would be better to discard the User class, as it closely resembles the Employee class.

The property IsAdmin is a very hard constraint, from a broader perspective you could create an Enum that represents security groups. This enables you to implement security for certain areas where given group X has access and group Y does not. This could replace the string SecurityLevel in the Employee class. You could also implement these security groups in the Permit class.

The Permit class should be used by the Employee class. A user can have multiple permits, active and non-active. A boolean value defining that logic should be implemented into the Permit class. By implementing the active/non-active boolean in the Permit class, you could revoke access by simply switching the value of the boolean.

Answer 3

In modeling business processes, it will often help to think about the paperwork , rather than the things in the real world. The process begins when somebody files a request document, it ends when the adminstrator files an approval or a rejection, and so on. The domain model's job is to do the bookkeeping, and to perform some of the logic on behalf of the business.

See

• Rinat Abdullin: Evolving a Process Manager...
• Greg Young: Stop Over Engineering

Should I create a UserId as well?

If you need to handle the case where the person submitting the request is different from the person the permit is assigned to, then you should absolutely treat those as different values.

It doesn't matter to me if I get only the EmployeeId or the Employee as a whole. Am I doing this right?

Yes - there is nothing wrong with an immutable value having an identifier.

In more sophisticated models, value objects will often be composed from other value objects. For example, event though EmployeeId and BloodGroup are opaque character sequences, it's probably not OK to pass a blood group to a method that is expecting an employee id, or vice versa. So rather than leaving things "stringly typed", we might invest more work in the model to make those concepts explicit.

How do I break down the properties of Permit into Value Objects?

Again, values can be composed from other values. If there is a subset of cohesive properties, group them together.

Scott Wlaschin's Domain Modeling Made Functional is a great reference here.

Part of the point of "objects" is that we should be able to change the in memory data structures and still have everything "work". So you shouldn't feel like you are committed to a particular in memory layout.

(Note: it's really easily to couple your in memory layout to your persistent storage -- that will make things harder to change later; so try not to fall into that trap more than once.)