
Domain Storytelling: A DDD tool to visualize domain stories in the browser - mablae
http://domainstorytelling.org/
======
PaulRobinson
What are the advantages/disadvantages you've found over event storming? Is
this just a good way to knowledge crunch with stakeholders to get to a good
analysis model, or do you find it leads to specific learnings you don't get
with any other method?

~~~
philipodonnell
"event storming" and "knowledge crunch with stakeholders" are two phrases I've
never heard before. Can you explain them?

~~~
cholantesh
I don't understand it in detail, but event storming is basically a workshop
for sharing knowledge about a problem domain. You get SMEs into a room with
whoever is executing (devs, designers, etc) on a project and, under the
guidance of a facilitator, have a time-boxed, business-oriented discussion
about the domain. You identify domain events, ie, all the interactions that
occur between users and system components.

~~~
philipodonnell
Thanks!

------
cpeterso
Interesting! With a domain model like this, a program could exhaustively test
all paths for invalid states. The model would need to some annotations of
invariants or could ask a human to review.

I highly recommend Eric Evans' book "Domain-Driven Design: Tackling Complexity
in the Heart of Software" (2003) mentioned on this page. It is a bit of slog,
but worth it.

Or for a quick introduction to domain-driven design, check out the (free
download) of "Domain Driven Design Quickly" e-book from InfoQ:

[https://www.infoq.com/minibooks/domain-driven-design-
quickly](https://www.infoq.com/minibooks/domain-driven-design-quickly)

------
dang
We changed the URL from [https://github.com/WPS/domain-story-
modeler](https://github.com/WPS/domain-story-modeler) to the project page,
which gives more background info.

------
mellett68
Very useful, I find that discovering domain knowledge can be a painful process
when trying to build a relationship with a new client. Hopefully this will
help

------
ai_ia
I was looking for something like a while back. Bookmarked.

------
pbadenski
Erm UML rediscovered? :]

~~~
wpietri
Nope. UML is a language for describing software systems. It's software first.
Domain-Driven Design is a focus on understanding the actual concepts of domain
experts. So this is people first.

As Martin Fowler said, “Any fool can write code that a computer can
understand. Good programmers write code that humans can understand.” That's
much more likely to happen if programmers start with the existing _human_
understanding of the situation.

As a contrast, let me describe two terrible code bases I worked on. The first
was something built by roving gangs of consultants. It was about donations and
corporate matching, but that was hard to tell by the code. It was basically a
giant snarl of HashMaps with magic keys that got passed around all over the
place, with bits of code fishing out things they needed. It mostly worked, but
it was incredibly hard to sort out because the code didn't _mean_ anything.

Another is the typical Java enterprise mess. I was once called in to advise on
an open-source product that was being built by consultants used to doing
banking work. Between being fetched from the database and rendered on the
screen, data was copied from object to object _7 different times_. ThisBean
and ThatBean and DTOFactoryIntializerStrategy. Most of the code base wasn't
really about the domain, it was cargo-cult rituals and architectural patterns
that had no practical value. Worse, having the domain knowledge smeared out
over a zillion objects means that their early domain understanding was locked
in, so the code base and the way people talked about the domain drifter
further and further apart.

At this point I'm a firm believer in Domain-Driven Design. If you really
understand how people think about what they do and then build the system in
those terms, you'll get a much better code base and a much better user
experience. Domain concepts are generally very stable, so your design is less
likely to go obsolete.

A good example is yesterday's article about building a real-time editing
system. They got good code because they really thought about the human
experience and then built in those terms:
[https://news.ycombinator.com/item?id=18220020](https://news.ycombinator.com/item?id=18220020)

~~~
keithb-
I'm not trying to nitpick, but UML is purpose-first, not solution-first. The
language always allowed for varying levels of abstraction (i.e. linguistics,
not layers), and it was always possible to describe the domain instead of
classes+methods, but one is always creating diagrams not code. For example, a
collaboration diagram can specify domain concepts and use plain language for
activities and artifacts; it is not necessary to consider functions and
arguments and exceptions. Oh my.

Your anecdotes are more common with object-oriented languages and poor object-
oriented design approaches. Any fool can claim to have discovered a OOD
pattern, but a good programmer will not claim to have discovered anything.
Instead, she will use the software to express the user's activity and desired
outcomes.

That being said, some software languages take more skill and experience to
implement a solution than others. Sometimes it is necessary for developers to
consider the choice of HashMap over List<?> or worse MyCollection which
implements List<?> over an array. These considerations may have created to
more types of diagrams (UML, OOD, etc.) that describe software in more an more
detail, but what is necessary to express a solution is really subjective and
rarely universally understood. You can't sit an inexperienced developer in
front of a C++ program and expect them to understand that they are looking at
code for a text editor anymore than you could sit them down in front of a
collection of DDD diagrams and expect them to build a perfect representation
in Java.

We (the royal "We") are looking for a proper balance in design and
implementation. That is a work-in-progress: it is the point of this career and
won't be captured by single checkbox on one's resume, e.g. "knows UML or not".

~~~
wpietri
> UML is purpose-first, not solution-first

I don't believe that's the case. If we set the Wayback machine for 1999, it's
pretty clear: "The Unified Modeling Language (UML) is the industry-standard
language for specifying, visualizing, constructing, and documenting the
artifacts of software systems. It simplifies the complex process of software
design, making a 'blueprint' for construction." [1]

It's very clearly about software.

[1]
[https://web.archive.org/web/19990127214541/http://www.ration...](https://web.archive.org/web/19990127214541/http://www.rational.com:80/uml/index.jtmpl)

------
simonmsims
Nice, might come in handy soon. Bookmarked.

