Can I do Domain Driven Design without domain experts? [closed]

Question

I often read that you should not do DDD when the team has no access to a domain expert. But what are the alternatives to DDD if the domain is not trivial but there is no domain expert available and the team only has access to a proxy domain expert or only to the product owner.

Shouldn't the team in this case create a common language accross the team, create a domain model within bounded contexts, use aggregates and aggregate roots to enforce business constraints, use repositories to ensure persistence ignorance for the model, etc?

I understand that DDD is not a whole or nothing and that it is not describing an architecture but a design methodology. But doesn't it make scence to use the tactical patterns and strategic design of DDD in case of a complex domain just because a domain expert is not available? Which part of DDD would I NOT use when no domain expert is available?

Answer 1

What you actually do need is a domain expert as a role, not necessarily as a concrete physical person (other than one or more development team member(s)). Having a 'real' domain expert is desirable, but not always possible. In such a case, the development team has to accumulate expert domain knowledge itself - not perfect, I know, but perfectly possible (and not so uncommon in practice).

Answer 2

First, I haven't read that you should not do DDD when the team has no access to a domain expert.

The main advantage of the Domain Model and Domain-Driven Design is usage of Ubiquitous Language. It is "a common, rigorous language between developers and users".

It is used to solve misunderstandings between developers and business.

A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design. The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person uses different language in speech and in writing, ...

(c) Eric Evans, DOMAIN-DRIVEN DESIGN

And either development team or business client should use the same vocabulary working on a project.

Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech.

Recognize that a change in the language is a change to the model.

(c) Eric Evans, DOMAIN-DRIVEN DESIGN

In your case it is enough to have "access to a proxy domain expert or only to the product owner".

In Scrum process Product Owner (PO) is a bridge between development team and stakeholders.

It is common when development team enforces business to use Ubiquitous Language, when developers who do business analysis and business people/ PO form this language together.

Sometimes business has several terms for single one 'entity', or 'process', or 'feature' and it is a challenge to select the correct one term.

Second, Since it is team's responsibility to make architectural decisions and design application, they can "create a common language across the team, create a domain model within bounded contexts, use aggregates and aggregate roots to enforce business constraints, use repositories to ensure persistence ignorance for the model, etc" when it is reasonable.

Third, I think that decision on doing or not doing DDD depends on requirements for software and doesn't depend on domain expert availability.