CODEWITHSUNDEEP
domain-driven-design
user437291
user437291

Reputation: 4651

Encapsulating processes within Domain Services

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

Upvotes: 0

Views: 131

Answers (2)

guillaume31
guillaume31

Reputation: 14064

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.

Upvotes: 2

eulerfx
eulerfx

Reputation: 37719

I think in p. 222 he's talking about a specific kind of process. So like in the p. 102 quote, they can be implemented as services. However, some processes refer to actual domain processes and can benefit from explicit representation in the model. This may not be immediately obvious and can call for more sophisticated object-models beyond services.

Upvotes: 1

Related Questions