CODEWITHSUNDEEP
domain-driven-design
Ryan Vice
Ryan Vice

Reputation: 2181

Approaches to creating your conceptual Domain Model

We are attempting to use DDD techniques on my current project and have started going through the process of domain modeling and are experience a lot of friction around "how to" create the Domain Model. I haven't found a lot of examples our guidance on this topic.

We have started by attempting to define the Ubiquitous Language by talking to the business users and coming up with a list of domain entities and their attributes. That's going pretty well but we are having problems with things like:

I have a lot of ideas on how we could capture all of these various things (sequence diagrams, uses cases, flow charts, ect...) but if there was a formal process or some resources providing example driven guidance it'd definitely speed things up a good bit.

Upvotes: 3

Views: 231

Answers (1)

MattDavey
MattDavey

Reputation: 9027

This is a great question.

One of the first steps I always take is to have a meeting with one (yes one) domain expert and have an open discussion about the problem domain from their perspective. I bring plenty of post-it notes and make sure I have plenty of whiteboard space. As the expert speaks I try to draw a flow or BPMN diagram on the wall using the post-its. I find it's very important to give the domain expert something visual to look at - something which he/she can physically point at and say "no, that's wrong!" (which they usually do, many times).

During these conversations I am listening closely to what the expert is saying and asking for clarification where there is ambiguity. I always find that it's better to let the ubiquitous language emerge naturally this way - rather than trying to forcefully establish it (I would never ask a domain expert to give me a list of terms).

I try to express the flow diagram in terms of commands and events - even if I do not end up using CQRS I find this naturally flows into more concrete requirements. When the flow diagram is complete (I can usually tell this because the the expert looks very pleased with it - there's a good chance he/she has never seen the domain mapped out this way and they are often thrilled by the novelty), I start to trace individual routes through the flow diagram. Often these individual routes can be easily expressed as behavioural specifications in terms of Given, When, Then style requirements. (see BDD section 3)

Once you have a collection of Given, When, Thens which cover every route through the flow diagram, you have sufficient specification to start the design phase of a domain model in exactly one Bounded Context.

I repeat the process with other domain experts. With subsequent experts I also listen for correlation between the language and terms they use. Most times different domain experts will share terms in the ubiquitous language, but will mean slightly different things. This is a sign that we are dealing with distinct bounded contexts.

Upvotes: 5

Related Questions