6

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?

Christophe
  • 74,672
  • 10
  • 115
  • 187
user1620696
  • 4,817
  • 7
  • 31
  • 46
  • 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 07 '17 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 09 '17 at 09:24

3 Answers3

13

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:

Christophe
  • 74,672
  • 10
  • 115
  • 187
  • 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? – RibaldEddie Jan 07 '17 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 08 '17 at 02: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. – RibaldEddie Jan 11 '17 at 03: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... – RibaldEddie Jan 11 '17 at 03:40
  • ... from interviews and discussions. Domain experts should not be expected to come from the software world, they should come from the domain. If you are writing software for law firms, then I think the domain experts should be lawyers. If you are writing taxi dispatching software then the domain expert is a taxi dispatcher. If you are writing hospital administration software then the domain expert is a hospital administrator. These experts cannot and should not know anything about software development processes and engineering. They need to be teamed up directly with developers to build... – RibaldEddie Jan 11 '17 at 03:42
  • ...the system. Otherwise you are playing "broken telephone" and by the time the software is written, debugged, and delivered, it will probably fail to meet the needs of the domain. This is why large scale projects often fail imho. The developers are so far removed from the domain expert that they build something weird instead of what was really needed and asked for. Every layer in between the domain expert and the developers is where the probability of failure increases. – RibaldEddie Jan 11 '17 at 03:45
  • @RibaldEddie i think that i don't say something else in my answer: domain experts should be from the user world. The best knowledge extraction is interactive (interviews, worshops, demo sessions). But sometimes writing is necessarye. And expressing requirements for a user has nothing to do with use cases nor anything Uml related. It's about business requirements (e.g the kind of writing you see in memos, reminders, or instruction to be followed by employees to get their travel expenses reimbursed). It's like user stories (e.g. "As an accountant i need a trial balance to control my daily data") – Christophe Jan 11 '17 at 07:15
  • One of the link speaks about test scripts. When from user, this has nothing to do with writing any it script ! In this context "script" means a detailed explanation of the successive user actions to be performed for the user to observe it's ok. So, I think we agree, and that there is just a misunderstanding of words that you interpret only with a software domain understanding, where these words can also have a different meaning. – Christophe Jan 11 '17 at 07:24
  • "...domain model, that is the domain in which the software will be used...." - domain model is not equivalent to domain. It is a subset of the domain, selected and adapted for the app needs – Alexey Aug 24 '19 at 18:57
  • @Alexey you’re right when you say that the domain model is not the domain. The domain model represents (in a simplified way) the domain. However I would not say that the model is a subset of the domain. There is a mapping between domain and domain model, but it’s a parallel world. For instance the accountant, as domain expert might not know anything about modelling, and as a matter of fact for some complex domains, the domain expert can even be unaware of the model (or use a mental model that is not consistent with the established model) – Christophe Aug 24 '19 at 19:08
  • 1
    @Alexey edited ! thanks for the constructive comment – Christophe Aug 24 '19 at 19:20
2

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.

paparazzo
  • 1,937
  • 1
  • 14
  • 23
0

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".

Mike Dunlavey
  • 12,815
  • 2
  • 35
  • 58