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

51–60 of 77 posts

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

#51

Post by molf »

tinco wrote: post #50
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…

One of my more painful design mistakes happened in this sort of way when designing a system for recording inspections. I interviewed multiple inspectors and came up with a representation that was a little bit more elaborate than I would have hoped, but it at least captured all information I believed. Then the company progressed and eventually we got to market fit and for two years the team and I were dealing with thi…

This seems like a business problem more than a design issue. Systems need to evolve alongside the business they support. Starting out with a simple design and evolving it over time to something more nuanced is a feature. Your colleague was right, and you were also right; except for the part where all nuances of the ideal solution need to be present on day 1.

The clients you have on day one are often very different from the ones you’ll have a few years in. Even if they’re the same organisations, their business, expectations, and tolerance for complexity likely have changed. And the volume of historical data can also be a factor.

A pattern I’ve seen repeatedly in practice: 1. A new system that addresses an urgent need feels refreshing, especially if it’s simple. 2. Over time (1, 3, 10 years? depending on industry), edge cases and gaps start appearing. Workarounds begin to pile up for scenarios the original system wasn’t built to handle. 3. Existing customers start expecting these workarounds to be replaced with proper solutions. Meanwhile, new customers (no longer the early adopter type) have less patience for rough edges.

The result is increasing complexity. If that complexity is handled well, the business scales and can support growing product demands.

If not… I'm sure many around here have experiences where that leads (to borrow Tolstoy: “All happy families are alike; each unhappy family is unhappy in its own way.”).

At the same time a market niche may open for a competitor that uses a simpler approach; goto step 1.

The flip side, and this is key: capturing all nuances on day 1 will cause complexity issues that most businesses at this stage are not equipped to handle yet. And this is why I believe it is mostly a business problem.

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

#52

Post by stevoski »

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 a fizz doesn’t yet belong to a buzz?”

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

#53

Post by thom »

BerislavLopac wrote: post #49

For the architectural documentation like this one, the C4 Model [0] is a much better fit than UML - primarily because it's less rigid in notation and modeling components. And in terms of tooling, I find IcePanel [1] to have the right combination of flexibility and simplicity. [0] https://c4model.com/ [1] https://icepanel.io/

The bottom layer of C4 is still basically UML, although everyone usually skips that.

I love IcePanel and would recommend everyone try it. But like all these things, it requires an almost superhuman level of commitment to get value out of it. It has built in mechanisms to keep you honest and up to date and I have found it useful both the strategic and tactical level when used right. But ultimately it’s difficult to build an engineering culture around long-term, living diagrams. The moment everything gets out of sync it might as well just be a photo of a whiteboard. I strongly suspect this sort of platform plus AI will be a great combination (I think at least one HNer is working on exactly that and I assume IcePanel too).

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

#54

Post by thom »

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…

Is there an equivalent of The Mom Test for talking to domain experts?

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

#55

Post by rapnie »

mdaniel wrote: post #33
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…

> 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 found this vid extremely funny as I've been in the same position sort of: "draw seven stricly perpendicular lines" asked of the dev by the sales team.

https://www.youtube.com/watch?v=BKorP55Aqvg

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

#56

Post by smcameron »

oleggromov wrote: post #20
whartung wrote: post #14

Earlier quoted context omitted.

I think folks upgraded to GML [0] [0] https://wiki.c2.com/?GalacticModelingLanguage

This is wonderful. Thank you.

Wait until you discover IGML (intergalactic modeling language)[1]. The entire user interface of a space game I'm working on -- including menus, buttons, sliders, even text rendering -- is literally implemented via a form of IGML. It's a very old language. Games like Asteroids and Battlezone have used it since forever.

[1] https://wiki.c2.com/?InterGalacticModelingLanguage

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

#57

Post by pydry »

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…

They're an awful substitute for code. About the best use for them is to give people an overview of the architecture of an existing system.

Even them theyre not great coz they tend to go out of date quite quickly and theyre quite expensive to build.

As a means of software design theyre BDUF crack - theyre an incitement to bad decisions in advance of writing software that would always be much better if done retrospectively via refactoring.

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

#58

Post by teeray »

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.

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

#59

Post by serial_dev »

mdaniel wrote: post #33
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…

> 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

It’s a great demonstration how unrealistic it is to use it.

If it is this complicated for a demo project for the purposes of the book, in my opinion, it shows it’s completely inadequate for handling anything remotely real.

Project ongoing for five years, 10 devs on the team, each year two resigns and two joins, some good, some mediocre, can you imagine them mess this will be? And that’s not even a large project, it’s just an average but real project size.

KISS / YAGNI goes a long way.

Post reply on HN