The best way to model the domain together with the domain expert - domain-driven-design

Question

I have done a fair bit of analysis and have used a number of tools to capture requirements: user created storyboards, use cases, GUI drawings, GUI prototypes, User stories & scenarios that can be used as acceptance criteria etc.
While each of these have more or less merit, I think there is one important bit missing. These methods can accurately capture how the user interacts with your app., but it is up to programmer to create and develop a “model” that should be reflected in the code.
I have been reading Evan’s DDD lately and he proposes something different. You need to create the domain model together with the domain expert and share it with him. In order to communicate the ideas with the user, in the book he often uses ad-hoc UML inspired drawings.
I wonder if this is the best way to talk about the model with the domain expert. Are there any other tools, besides UML diagrams, that you could use to capture the domain knowledge and use it while you are discussing the domain with your domain expert?

Answer 1

While the final abstraction into a working domain model (and ultimately a stable model) is your, the developer's, job, I do agree that even the set of tools above can be restricting, and limiting yourself or your communications to just UML can make the conversation seem esoteric to the domain expert.
For systems anatomy, try Block Diagram notation tools at http://www.fmc-modeling.org/.
For white/blackboarding and mind-mapping try FreeMind
For associative organization (and coolness) try TheBrain
For quicker/collaborative graphing (sort of new), try LucidChart
And of course, good ol' Dictionary and Thesaurus to always, always strive for the best terminology.
If these seem right-brained to you, remember that modeling is left-brained analysis done by one party on behalf of two. You're not going to get as much with a purely defined linear process as when that is coupled with trial-and-error, free-running style information mining.

Answer 2

The best way is pencil and paper. UML and what not come after this. Start with a DSL (list of vocabulary that is used when talking about the domain). Then you can use that list to determine what is actually what (model, aggregate, action [verb], etc) then you can do associations.
After all that, then do your UML diagrams and go over it with the domain expert. If they understand it then you're golden.
This book covers doing exactly what I said. I recommend at least skimming this book (actually I dont know if you're using .NET). http://www.amazon.com/Professional-Refactoring-ASP-NET-Wrox-Programmer/dp/047043452X/ref=sr_1_1?s=books&ie=UTF8&qid=1306529986&sr=1-1

Answer 3

There are losts of/ tons of tools THAT you can use:
Actor Map
Actor Table
Business Policies
Business Rules
Context Diagram
Decision Table or Decision Tree
Domain Model
Event Table
Process Map
Scenarios
Statechart Diagrams
Use Cases
Mind Maps
..
There are so many long and boring books about each of them. And sometools work at some context "best" and "may failed" at others. There is nothing like "BEST": Context matter.
But the important thing is not the techniques themself: Important one is How you apply them....
.
The trick is how to "Collaborate" with customers-domain experts-end users.
Collaborative-Workshops generally best at many context. The following book does a nice job at this area.
Requirements by Collaboration: Workshops for Defining Needs ,Ellen
Gottesdiener
Check http://ebgconsulting.com/facassets.php
But be carefull DO NOT BE A TEMPLATE ZOMBIE [ which is a general disease in requirements area ]
And you can use even games for making better Collaboration:
Innovation Games: Creating Breakthrough Products Through Collaborative
Play , Luke Hohmann

Answer 4

Domain experts tend to understand sentences better than anything else. That's why I like Object-Role Modeling. A lot of the development relates to graphical methods, but in practice I find it works best to just use the structured sentences.

Answer 5

I personally find most productive way to just sit down and write domain model on-fly while frequently asking yes/no questions to domain expert that sits next to me. this works only if You are fast enough w/ coding.
Also - well constructed (trees should read like sentences) mind maps in ubiquitous language are great way to communicate. Easy to create, share and understand too.
Real world example:
Payment
comments
can be edited
if user is authorized
with role [Role]
can be approved
if user is authorized
if payment is initiated
if payment is not paid yet
if amount does not exceed allowed budget
when approved
remembers that
saves approving date
can be rejected
if something something...
when rejected
forgets planned pay date
resets amount to be paid
(copy from here if You want to see it in text2mindmap tool)
That translates into:
public class Payment{
public virtual void EditComments(string comments){
Authorize<EditPaymentComments>();
CommentsEntered=true;
CommentsEditedBy=User;
CommentsEditedOn=SysDateTime.Now();
Comments=comments;
}
public virtual void Approve(){
EnsureCanBeApproved();
IsApproved=true;
ApprovedOn=SysDateTime.Now();
Raise(new Approved(this));
}
protected virtual void EnsureCanBeApproved(){
Authorize<AcceptPayments>();
ThrowIf(!IsInitiated,
"Payment is not initiated.");
ThrowIf(IsPaid,
"Payment is already paid.");
ThrowIf(ExceedsAllowedBudget(ToBePaid),
"Amount to be paid exceeds allowed budget.");
}
public virtual void Reject(){
EnsureCanReject();
ForgetPlannedPayDate();
ToBePaid=0;
IsInitiated=false;
IsRejected=true;
Raise(new Rejected(this));
}
private void ForgetPlannedPayDate(){
Deadline=DateTime.MinValue;
DeadlineKnown=false;
}
}

Answer 6

There are many good suggestions so far for tools. Try them and use the ones you like, but the key to success is iteration between code and conversation... what Evans calls knowledge crunching. The more you listen to the domain experts, model what you hear in code, then show them the software, get feedback, and tweak the model, the closer you will come to software that solves the problem at hand.

Answer 7

For me, it depends on the domain expert.
For some, it is a matter of sketching a UI on a whiteboard - showing how it would look on screen - then asking questions like: "Can this one exist without that one?", "Do you have situations, where this one is first added later, or are they always there", "Which order would you prefer them filled out?", "Who needs to know what from this screen?"... Usually, the visual aid helps them get into a situation where they can actually answer your questions very precisely.
Others, I can use naive UML (showing aggregates, valuetypes, properties and collections) and they are fine with that.
Really, to me it is quite simple, I start out simple - keep adding techical stuff until they go blank in their eyes - then take back one step. And always have some kind of starting position to get the creative juices flowing. If you're stuck, just watch'em work - "Wait a minute - why did you not record that information?", "Whoa, you did what there?" - to me, the tools are only there to help me, they rarely help the domain expert.
Basically, knowledge crunching with few to no tools beside a pen and paper (and a whiteboard if possible).

Answer 8

What I do is to create use case diagrams for requirements. I can save all needed information at model level. My use case diagram could save almost all the complex needed system I have to model.
I also can reuse the same use case in more than one diagram and still keep its property. Really superb technology.
Concerning domain with UML I nix use case and class diagram element in the same diagram and all add a database profile which allows me to add persistence in my class diagram. This is therefore object modelling with database specifications.
My modelling is really complex, I create my database and can permanently refactor my requirements and immediately my code without loosing my model.
I use it daily and really like it.
Hope this help.