4 ms·

Domain Storytelling: A DDD tool to visualize domain stories in the browser

137 points by mablae 8y ago

dang 8y ago
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.
ai_ia 8y ago
I was looking for something like a while back. Bookmarked.
deleted 8y ago
[deleted]
mellett68 8y ago
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
simonmsims 8y ago
Nice, might come in handy soon. Bookmarked.
PaulRobinson 8y ago
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 8y ago
  "event storming" and "knowledge crunch with stakeholders" are two phrases I've never heard before. Can you explain them?
  - cholantesh 8y ago
    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 8y ago
      Thanks!
pbadenski 8y ago
Erm UML rediscovered? :]
- wpietri 8y ago
  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
  - philmander 8y ago
    There seems to be some overlap with a UML business use case which can be used for modelling requirements.
cpeterso 8y ago
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

137 points by mablae 8y ago

dang 8y ago

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.

ai_ia 8y ago

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

deleted 8y ago

[deleted]

mellett68 8y ago

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

simonmsims 8y ago

Nice, might come in handy soon. Bookmarked.

PaulRobinson 8y ago

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 8y ago
"event storming" and "knowledge crunch with stakeholders" are two phrases I've never heard before. Can you explain them?
- cholantesh 8y ago
  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 8y ago
    Thanks!

pbadenski 8y ago

Erm UML rediscovered? :]

wpietri 8y ago
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
- philmander 8y ago
  There seems to be some overlap with a UML business use case which can be used for modelling requirements.

cpeterso 8y ago

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