Question

Note – all quotes are from DDD: Tackling Complexity in the Heart of Software

First quote ( page 222 ):

Processes as Domain Objects

Right up front let’s agree that we do not want to make procedures a
prominent aspect of our model. Objects are meant to encapsulate the
procedures and let us think about their goals or intentions instead.

What I am talking about are processes that exist in the domain, which
we have to represent in the model. When these emerge, they tend to
make for awkward object designs.

The first example in this chapter described a shipping system that
routed cargo. This routing process was something with business
meaning. A Service is one way of expressing such a process explicitly,
while still encapsulating the extremely complex algorithms.

Second quote ( pages 104,106 ):

Sometimes, it just isn’t a thing. In some cases, clearest and most
pragmatic design includes operations that do not conceptually belong
to any object. Rather than force the issue, we can follow the natural
contours of the problem space and include Services explicitly in the
model.

When a significant process or transformation in the domain is not a
natural responsibility of an Entity or Value Object, add an operation
to the model as a standalone interface declared as a Service. Define
the interface in terms of the language of the model and make sure the
operation name is part of the Ubiquitous language.

I can’t figure out whether in first quote author is using the term “processes” to describe the same type of behavior ( which should also be encapsulated within a Service ) as in the second quote, or is the term “processes” used to describe a rather different kind of behavior than one he’s describing on pages 104, 106?

Thank you

Answer 1

The concepts are pretty close but to me, the first quote looks more like it’s about large real-world domain processes that would exist without the software (e.g. “a cargo routing process”).

Second one is less clear but I think it describes smaller operations/processes/transformations taking place in the modelled version of the domain.

While the first kind should immediately click as “Service” right from early analysis stages, the latter is more subtle and could take more time to be distinguished from regular entity behavior – you could have included it in an entity at first but realize it doesn’t fit that much in it as you refine the model.