How to deal with cross-domain concepts in DDD?

Viewed 202

Let's say I have a class that provides calculations or concepts that are used by different domains. Since domains are in their own "bubble" and have no idea about the outside, I would have to copy this class in every domain, right? Or is there such a thing as a utility domain? I would like to avoid maintaining the same class in several domains.

I'll try to give an example: Suppose I have invented a new concept of time. An hour no longer lasts 60 minutes, but about 70. A day now lasts about 22 hours and also the date looks different. Now I want to build a store system with the following subdomains: Order, Contract, Delivery, and Invoice. Each subdomain now uses this new time concept. Whenever a time unit is needed, the new time concept should be used. This can happen in all subdomains.

1 Answers

If this elements (classes, functions etc) are shared between several sub-domains, you could build a shared domain. Better would be if this elements are part of a named shared domain so it's not just 'shared'.

For example, you could have to manage entities like Car, Motorbike and Bus. All this entities, after some analysis, share some elements. For example, they all have an Engine, Tire (more than one), an IdSign. You can share all this elements in a common entity, Vehicle. All the entities derive from this, and extend/improve it's base functions. In this way you build a shared domain that is extended by the other domains.

On the other side, you could have this functions totally disjointed from the entities of the domain. I mean, you could have a function 'find the number of minutes between two (local) hours' that is totally disconnected from the Vehicle and it's sub entities. This kind of elements should stay in an utility package, that live it's own life and is used inside the domain that you're going to design.

But, if you are going to design something around the Clock entity, the same function of before would be placed in a totally different package.

That means, the best solution for your problem depends totally on your domain and the way you're going to design it.

Related