Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UML diagram for the DDD example in Evans' book

github.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: UML diagram for the DDD example in Evans' book

#71

Post by motorest »

neilv wrote: post #8

I used to work heavily in this kind of system modeling (developing tools for it, and dogfooding), and still use it when high-value for figuring out or communicating an aspect of a system. Here's a challenge, to help appreciate the nature of these: try to find an error in the diagrams. It's usually harder than you might think, since, even when you know the notation and metamodel semantics, it's information-dense talki…

> Here's a challenge, to help appreciate the nature of these: try to find an error in the diagrams.

The point of diagrams is to communicate concepts and ideas. They are a design tool, not a design goal. They are used to help reason about your design. One of the most basic uses is to step through each of your requirements and verify if the design meets each and every single one of them.

> For example, large amounts of work that have to be redone, or a project abandoned (...)

No, this is not the diagram's fault. That's a problem caused by poor or even inexistent design. You only need to redo a project if you fail to meet critical requirements and you can't figure out a way to make them work with what you have. The diagrams only convey the output of your design process, and if it is faulty then it's not the diagram's fault.

Re: UML diagram for the DDD example in Evans' book

#72

Post by motorest »

RealityVoid wrote: post #41
mdaniel wrote: post #33

Earlier quoted context omitted.

> try to find an error in the diagrams. Easy peasy, it's the 3rd blue line above the purple line /s https://github.com/takaakit/uml-diagram-for-ddd-example-in-e... I can't believe someone took time to generate such a thing, as if it is useful to anyone

> I can't believe someone took time to generate such a thing, as if it is useful to anyone Thanks for saying this. UML is beyond useless, almost nobody understands it, almost nobody does it right and almost nobody uses it when they need to (because it makes no sense to them).

> UML is beyond useless, almost nobody understands it, almost nobody does it right and almost nobody uses it when they need to (because it makes no sense to them).

I completely disagree. UML is one of the best tools to communicate system designs and behavior in a high-level language that is easy to understand. Like everything in software engineering, you can make things very hard to understand or you can focus on making things easy to understand, and if you do not take the time to familiarize yourself with the basics them everything sounds very complex and useless to you.

Re: UML diagram for the DDD example in Evans' book

#73

Post by motorest »

teeray wrote: post #58
alganet wrote: post #25

Good UML is really simple UML. "Then what about complex things? Can't make everything simple" Do partial diagrams. Simplify or skip things your team already knows. Also, great UML is no UML. Sometimes the code itself is short and clear enough, requiring no diagram (of course, not all diagrams are about code... but use case diagrams are rare these days anyway). Also, use cases and use case diagrams are great. Also, pe…

This is why UML only belongs on a whiteboard. It makes it much harder to include unnecessary detail when you have to physically add it, and there’s hard real estate constraints.

> This is why UML only belongs on a whiteboard.

UML belongs in whiteboards, design documents, and project documentation. I don't know where else people expect to use it. I mean, does anyone expect to generate anything out of a sequence diagram?

Re: UML diagram for the DDD example in Evans' book

#74

Post by motorest »

stevoski wrote: post #52

Analyst: “So this part of the UML diagram is right? A fizz always belongs to a buzz?” Domain expert: “Yes, always” Analyst: “Any exceptions you can think of?” Domain expert: “No, none at all.” —- Forward to day 1 after “delivery” of the implemented system. Domain expert is now using the system for the first time in a real-life situation: “It doesn’t let me save the fizz I’m creating. How does this handle a case where…

> “It doesn’t let me save the fizz I’m creating. How does this handle a case where a fizz doesn’t yet belong to a buzz?”

You are not describing a scenario that involves diagrams of any kind. You are describing a scenario where an analyst missed critical requirements and failed to accommodate them in a design. Blaming UML for a design mishap is like blaming your notepad for you failing to buy some groceries.

Re: UML diagram for the DDD example in Evans' book

#75

Post by teeray »

motorest wrote: post #73
teeray wrote: post #58

Earlier quoted context omitted.

This is why UML only belongs on a whiteboard. It makes it much harder to include unnecessary detail when you have to physically add it, and there’s hard real estate constraints.

> This is why UML only belongs on a whiteboard. UML belongs in whiteboards, design documents, and project documentation. I don't know where else people expect to use it. I mean, does anyone expect to generate anything out of a sequence diagram?

I really meant that the constraints of drawing it by hand forces you to draw only what matters
Post reply on HN