Domain-driven project: how to work with complex models with a large number of data fields?

Question

Well, I'm trying to apply domain-based design principles for my application, with a rich domain model that contains both data fields and business logic. I have read many DDD books, but it seems that their domain models (called entities) are very simple. This becomes a problem when I have a domain model with 10-15 data fields, such as:

class Job extends DomainModel{ protected int id; protected User employer; protected string position; protected string industry; protected string requirements; protected string responsibilities; protected string benefits; protected int vacancy; protected Money salary; protected DateTime datePosted; protected DateTime dateStarting; protected Interval duration; protected String status; protected float rating; //business logic below } 

As you can see, this domain model contains many data fields, and all of them are important and cannot be deleted. I know that a good rich domain model should not contain customization methods, but rather pass on your data to the constructor and mutate states using business logic. However, for the specified domain model, I can not pass everything to the constructor, as this will lead to 15 + parameters in the constructor method. The method should not contain more than 6-7 parameters, what do you think?

So what can I do to deal with a domain model with a lot of data fields? Should I try to decompose it? If so, how? Or maybe I should just use the Builder class or reflection to initialize its properties when creating the instance, so I won’t pollute the constructor with so many arguments? Can anyone give some advice? Thank you

Answer 1

What you missed is the concept of the Value object. Value objects are small, immutable objects with a value in the corresponding domain.

I don’t know the specifics of your domain, but looking at your Job object, there may be a value JobDescription object that looks like this:

 class JobDescription { public JobDescription(string position, string requirements, string responsibilities) { Position = position; Requirements = requirements; Responsibilities = responsibilities; } public string Position {get;} public string Requirements {get;} public string Responsibilities {get;} } 

This is C # code, but I think the idea should be clear, regardless of the language you use.

The basic idea is group values, which makes sense in the corresponding domain . This means, of course, that value objects can also contain other value objects.

You should also make sure that value objects are compared by value and not by reference, for example. by implementing IEquatable<T> in C #.

If you reorganize your code with this approach, you will get fewer fields on your entity, so using the constructor installation (which is highly recommended) will be possible again.

---

Additional notes regarding your sample code that are not directly related to the question:

• A domain model is everything, an entity is part of it. Therefore, your base class should be called Entity , not DomainModel .

• You must make the fields of your class private and provide protected accessors where necessary to support encapsulation.

Answer 2

There are a lot of tasks in your domain model object: it seems that a huge number of problems are mixing, and (at least for me) it offers a number of limited contexts, some of which are easy to distinguish for the sake of example.

• Remuneration (payment, benefits)
• Organizational position (reporting line)
• Personality Specification (Skills)
• Specification of work (duties)
• and etc.

When you consider things that interact with your Work model, are there any that should test or mutate the BOTH Salary property and the Industry property, for example?

Not knowing the full nuances of the domain, the salary that you get for the position and the industry in which you work are not really connected, are you? Not a rhetorical moment; these are questions you NEED to ask domain specialists.

If they DO NOT have any interaction, then you have determined that these two things exist at two different END OF CONTROL. The Salary side does not need any interaction with the industry side and vice versa, and even if they did, do they need to simultaneously keep the state in one process?

Think about the life cycle of how a person becomes an employee; the person is applying for a job. The assignment has a specification, a range of salaries. A man attends an interview. Employers offer a person such a position. The person accepts. The person is now an employee, not a candidate. The new employee now receives vacation and benefits, has a start date, etc.

DDD teaches us that a single, single view of the world rarely satisfies ANY of the problems. Please study the BASIC CONTEXTS - as a result, your software will be much more flexible and flexible.