Abstract Domain DDD

Question

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?

Answer 1

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:

• Communication risk: your model will be more difficult to share with the business experts. They might get confused with your abstractions. This might quickly result in the feeling of not being understood, and tensions might arise.
• Accuracy risk: the business experts will naturally mentally map your abstract ticketing entities to the concrete concepts that they use in their daily life. If you don't catch the consequences of this semantic confusion, your abstract layer might quickly end up to be very specific.
• Project risk: by trying to deliver two things at a time, i.e. an abstract engine, and a concrete adapter for it, you may be confronted with lots of additional issues that might jeopardize your main project.

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:

Bounded context: The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently.

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:

Context Map: A representation of the BOUNDED CONTEXTS involved in a project and the actual relationships between them and their models.

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.

Answer 2

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.

Why?

Your domain should be where your business rules live. Are none of your business rules specific to the airline part of an airline booking system? If not why did you let the airline detail in the system at all?

If some business rule needs the concept of "airline" then that belongs in the domain. I could see pulling abstract ticket booking system functions out into library functions that don't have the concept of airline. But that doesn't take over your domain. It supports your domain. Push that ticketing library off to an outer layer.

I can say the same thing for vertical pivots. If you want that abstracted away from airlines or booking systems write a vertical pivot library and use it. Use that in your domain. Just don't use it AS your domain.

This might seem counter intuitive. You might have been thinking the domain was the most abstract part so the ticketing system getting more abstract demands that it be more central. This isn't what a domain is. A domain pushes away what isn't focused on your expressing your business rules. a DB or a GUI can be very abstract. That isn't a reason to put them in the domain.

The domain is where someone who doesn't understand the details of the system but does understand the business can look and see business rules expressed in a language they understand.