In Domain-Driven Design much is said about the domain experts. They are the ones who knows about the domain, and which should be in contact with the developer in order to build the ubiquitous language and hence the domain model.

The only problem I have is that from a practical point of view I don't know who the domain experts are: Are they the end users? Are they the people who asks for the development of the software? Are they random people that deal with the problem being solved by the software?

From a practical point of view, who are the domain experts and where should I look for them when building a software?

  • 2
    That depends on the kind of software your are building, the domain, of course, and the organizational environment where the software is developed. If you are building a bigger program, it might be possible that you have different domain experts for different groups of features. There is no hard rule for this.
    – Doc Brown
    Jan 7, 2017 at 16:48
  • The domain experts are the people who will be laid off when your application is deployed, as they are no longer needed.
    – Simon B
    Jan 9, 2017 at 9:24

3 Answers 3


What is a domain expert ?

When you develop software using Domain Driven Design, the primary focus should be on the domain model, that is a representation of the domain in which the software will be used.

Let's take the example of an accounting software. The domain is accounting, and to build your domain model, you need to identify domain objects (e.g. accounts, debit, credit, postings, ledger, ...) and the rules that govern them (e.g. "in a posting, the sum of all the debits must always be equal to the sum of all credits", or "once a posting made in a ledger, you're never allowed to delete it", or "for every posting, there must be an audit trail of who posted it when").

To develop your model (and your software around it), you need to get the domain knowledge. This knowledge could be extracted from available sources (books, business procedure manuals, ...), but to get it right, you need a domain expert (sometimes called a subject matter expert).

What are the domain experts ?

In the accounting example, the domain expert would probably be an accountant. He/she may probably be or become a future user of the system (some call him/her a "key user" for this reason). But in other cases, it could be a business expert that will never use the system (e.g: a production engineer knows perfectly the production line and the production process, whereas the future users will be the production operators).

Keep in mind that not every user will be a domain expert. A domain expert must have some authority on his domain, so that you can verify with him/her the validity of your designed domain model.

Last but not the least, for many systems, you might need several domain experts to cover the full spectrum of the domain, because nobody can know it all (e.g. for an ERP you need domain experts from all over the company: sales, procurement, accounting, production, warehouse, ...).

Where to find the business experts ?

It's difficult to give a universal answer. I can only tell you what worked for me: I think the best way to find them is to ask the customer of your future system.

Ask for an expert who can describe what the system shall do, who can explain how the business works in the considered field, and who could answer the more complex questions you could have about the topic.

Ask for someone who has authority to approve orientations and choices about how the software fit the domain needs.

Additional reading:

  • 1
    I like your answer but the link you posted under additional reading contradicts your post, in my opinion. Can you say more about what a reader should expect to learn from the link? Jan 7, 2017 at 20:23
  • @RibaldEddie I was looking at the enumerated 5 tips which IMHO match my recomendats when read with the idea of selecting a domain expert from the client company. But indeed, the introduction is formulated in a manner that one could imagine a consultant as well, which was not what I meant.
    – Christophe
    Jan 8, 2017 at 2:27
  • 1
    I'm not talking about consultants. Take your example of the accounting software. I think you're right that the domain expert should be an accountant. But everything you've linked to seems to suggest that the domain expert should be someone good at writing requirements documents and that a domain expert can work on multiple projects, for example as a consultant, but that doesn't make sense given that what matters is expertise in the domain. A brilliant accountant who knows everything about how accounting works probably doesn't know anything about software requirements. Jan 11, 2017 at 3:36
  • Think about it. In order to write a good requirement doc you need to know about use cases, flow diagrams, functional vs non-functional requirements, and a lot of other things that specifically have to do with the creation of software. Why would a good accountant know these things? Would we expect them to? I think the domain expert doesn't know anything about software requirements unless the domain itself is software engineering processes. Business analysts and or product managers and or software architects and or developers need to sit down with the domain expert and build requirements... Jan 11, 2017 at 3:40
  • 1
    @Alexey edited ! thanks for the constructive comment
    – Christophe
    Aug 24, 2019 at 19:20

To me proper academic training and substantial work experience in the field. Other workers come the them for advice. They are not just an expert by authority.

You also need someone understands the difference between a requirement and a design. For most programmers it is natural but you get users that really cannot abstract from design to requirements. They cannot talk about data, data relations, and business rules without talking about a button.

For an in house product then someone from withing. For an general commercial product some that has worked at more than one company.


Personal experience:

To me, the domain experts are the people who will be using the tools I build.

They cannot design a tool or a domain specific language - that's a skill they don't have. (They may think they can, but they can't. They don't know how to generalize.)

I have to ask them about what they do. (This used to be called "knowledge engineering" :) It's even better if I can try doing what they do.

(Many programmers on these sites seem to think they only need to know how to program, and it's just a matter of being told what to do. Wrong! You have to get in the user's head. In my case this involved dusting off a lot of long-ago math courses.)

Then I prototype a tool/language and explain it to them, or let them try it. They tell me what is wrong with it, and we do it all again. By about the third try, it's a pretty useful tool.

There are lots of "methodologies" out there, like "waterfall" and "agile". To me, the one that works best is "rapid prototyping".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.