Domen managed architecture and custom typos / bugs

Question

DDD teaches us to build our classes as their prototypes of the real world.

So, instead of using setters

job = new Job job.person = person job.since = time.Now() job.title = title 

we define well-known methods in our aggregation root

 job = person.promote(title, /** since=time.Now() **/) 

Now the tricky part

Suppose we have a UI for HR, where he enters a new title through the HTML form and makes a typo like "prgrammer" (of course, in the real application there will be a selected list, but here we have text input) or selects the wrong date (for example, by default today)

Now we have a problem. There are no typos in the real world. Our John Doe is definitely a "programmer" and never a "programmer"

How do we fix this typo in our domain model?

Our Person has only promote , demote , fire , etc. methods that reflect the HR domain model.

We could cheat a little and modify the Job entry directly, but now we have a Job.setTitle method that does not reflect our domain model, and the setters are evil, you know.

It may seem a little “academic,” but it really scares me when I try to create a good domain model for a complex application.

Answer 1

The other side of DDD is invariants - the " always valid " entity. And when you try to break this invariant (some rule), you should stop execution and say “loudly” adout this (throw exception). So, you need to have a list of valid captions, and when you try to change the title (it doesn't matter how) to an invalid state, you should throw some useful exception.

To “fix” typo situations, you must separate the operations in your promote domain - this is one operation (it can check something, send an email with the opposite treatment :), etc.). The edit operation is only for editing some properties. Thus, the differential is in the logic of operations. You cannot call promote without any preconditions (for example, the necessary experience of the employee), but you can call edit and correct the name of the artist due to the type. And usually these operations are divided between different users: only HR can promote , but the worker can edit his name if it is erroneous. This solution is very difficult for such an example, but it is always with DDD. The basic concept is separate operations. Each of them has its own conditions, permissions, rules.

A question about invariants (rules).

Answer 2

If the client is purely entering data, then the underlying domain in this (limited) context is not very deep. In these cases, it’s great to use a CRUD style application and allow the change of titles ( setTitle() ).

Just make sure that dependent BCs (like billing, vacation planning, ...), where there is no such thing as “invalid data”, can respond accordingly to changes in your CRUD context.

Answer 3

The application must ensure that the input is correct before it reaches the domain level, without entering garbage. If this means using a drop-down list for job titles, let it be. You can check the title with existing titles.

In my company, out of 18 thousand employees, a typo occurs all the time. You will have to be pragmatic about this and agree that there will be some setters in your code (one way or another)

Pragmatic thinking is at the core of a domain-driven project, and this is what makes things simple.

“Purity is good in theory, but in practice it can be very difficult to achieve, and sometimes you have to choose a pragmatic approach” - “Templates, principles and practice of domain-oriented development” (2015)

Answer 4

“There are no typos in the real world,” I understand what you mean, but it’s not, in real scenarios there are human errors, and they should be taken into account in your domain, if they are frequent.

If data entry errors are not frequent, this may not be practical for additional modeling efforts, and perhaps they can simply be installed directly in the database. It also depends on whether the business wants to know something about these errors or not.

However, if data entry errors are frequent, this may be an indicator that the system may not offer enough instructions, and the business may wish to learn more about these errors in order to make processes more efficient and less error prone.

Perhaps you want to implement an operation such as job.correctTitle(...) , perhaps in BC, dedicated to data fixes? In addition, it is probably very rare that each piece of information will be erroneous, so corrective operations can be divided. This means that you probably do not need the job.correctAllInformation(...) operation.

This whole scenario is very fictitious, because the names of the work are usually managed in a separate BC, from where they are used, and they are likely to be selected from the list, so typos will be less frequent, but you will always have to deal with data entry errors. Choosing the right solution is not always easy and will vary from case to case, but try to remain pragmatic and not strive for the perfect model in all areas of your domain.