Most domain driven design examples are for explicit domains – Accounting interface, Airline booking systems, and such.
Sometimes, your domain is much more abstract than that.
In my case, the application is built around a specific domain, but a very important aspect of the application is the ability to pivot to other, very similar, verticals.
The question is, how would you model such an application? Each vertical has its own ubiquitous language and the domain models may have different names but the domain logic is basically the same.
What I am currently trying to do, which I am not sure if it is correct – is decouple the project models from a specific domain, and think of them abstractly. So, instead of airline booking system – it becomes a more abstract ticket booking system.
The drawbacks of this method are obvious, it abstracts us from the domain, and breaks a lot of the idea behind ubiquitous language.
The other option I can think of is to tie the model to our current specific domain – but this has the issue of tying us to our current specific domain, and it makes pivoting to other domains a lot more difficult.
Anyone tried pivoting from a specific domain model? Is it as hard as I can imagine?
Best Answer
Preliminary remark about your approach: caution !
Starting to model a specific domain (e.g. airline ticketing) is challenging. Trying to abstract a part of this model for later potential reuse (e.g. railway ticketing, olympic game ticketing, hotel booking, etc...) comes with three significant risks:
When to do it ?
If the abstraction is done only for the purpose of a generic implementation, my advice would be to use another approach: first take care of your initial ticketing system and keep the domain model clean, then refactor.
Nevertheless, ticketing is a business domain of its own. And some practices cross the borders of their original industry. For example, in Europe, many railway companies have adopted airline-like ticketing principles (and systems). Some general problems like dynamic pricing, yield management, etc... are even recent innovations that are worth to be handled as original business concepts.
So, if your abstraction is in fact about modeling a more general business domain, with a buisness value of its own, your approach could definitively be justified.
How to do it with DDD ?
The situation that you describe is in fact quite common in large and compex projects: several domains may have to interact. Evans addresses it explicitly in his big blue book:
Interestingly, in the part about strategic design, in chapter 14 he gives as example a shipping business, and identifies booking system as a distinct bounded context.
The principle of bounded contexts is that there may be several domain models, each defined in a bounded context. The ubiquitous language applies within a context.
In order to keep the overview and ensure consistency, a global context map shall depict the main concepts of the different contexts, and map across the boundaries the related concept:
If the above link to Fowler's article is not sufficient, I'd recommend you to read more about this topic in Evan's book. It's definitively worth its money, if you're professionally using DDD.