This project uses UML diagrams to illustrate the structure and behavior of the DDD example—a cargo shipping system—from Eric Evans’ book (Domain-Driven Design: Tackling Complexity in the Heart of Software). These diagrams are created based on the source code of the dddsample-core project on GitHub. The diagrams aim to help us understand how the example implements the strategic and tactical designs of DDD and the mechanisms by which it operates.
If you want to get into DDD theory, check out Evans’ book. If you want to get into the implementation details, check out the source code of the dddsample-core project. Also, if you want to understand the UML model behind these diagrams, open the model file (ddd-example-in-evans-book.asta) using the modeling tool Astah Professional/UML/Viewer.
Clicking on the UML diagram image below opens it in Diagram Map *1.
*1: Diagram Map allows you to zoom and pan, like Google Maps, when viewing a UML diagram. You can view it with any browser. To create one on your own, Astah Professional/UML and the m+ plug-in are required.
This sequence diagram illustrates the key interactions between the user and the system, with references to other diagrams. The interactions show two use cases: (1) tracking the handling of specified cargo, and (2) booking new cargo followed by assigning it a delivery route.
This class diagram illustrates the basic elements of the domain model and their relationships. The layout of the domain model elements is based on the diagram presented in the dddsample-core project. Attributes and operations are hidden to focus on understanding the elements and their relationships. If you want to see them, open the model file (ddd-example-in-evans-book.asta) using the modeling tool Astah.
This object diagram shows the basic domain objects and thier connections. In particular, it shows the object snapshot associated with the cargo object “ABC123,” which is preset as sample data. The cargo “ABC123,” which is en route from HongKong to Helsinki, is currently at the port of New York, where unloading has been completed.
This class diagram illustrates the overall structure of the cargo shipping system: it is composed of two contexts, the Booking context and the Transport network context. The system is implemented using Spring projects such as Spring Boot / MVC / Data JPA. Note that this diagram focuses on elements and relationships that may be considered and does not reflect the entire implementation. Attributes and operations are also hidden to focus on understanding the elements and their relationships. If you want to see them, open the model file (ddd-example-in-evans-book.asta) using the modeling tool Astah.
This communication diagram illustrates a scenario in which the user launches the cargo shipping system, with a focus on messages that may be worth considering.
This communication diagram shows a scenario in which the user requests tracking for cargo “ABC123” on the cargo tracking page. The cargo “ABC123,” which is preset by the system and en route from HongKong to Helsinki, is currently at the port of New York, where unloading has been completed.
This communication diagram shows a scenario in which the user registers new cargo on the cargo booking page. The new cargo is set to be shipped from New York to Helsinki.
This communication diagram illustrates a scenario in which the user requests cargo routing on the cargo booking result page, followed by the presentation of route candidates.
This communication diagram illustrates a scenario in which the user requests to assign new cargo to a delivery route on the route selection page.
This is a directed graph *2 that represents the structural elements and their relationships, associated with the Booking context and the Transport network context. This graph allows you to view the element relationships in various layouts. Note that the node colors in this graph are automatically assigned on a per‑folder basis and do not correspond to
9 Comments
ak_111
What happened to UML? I remember it was everywhere in enterprise computing 20 years ago but seems to have disappeared now.
Is it still around or did it go the way of SOAP, Java Applets? If not, what has replaced it?
neilv
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 talking about a domain.
You usually have to know or learn a lot about the domain, and/or have an domain expert you can walk through it exhaustively, before you can find errors.
And an error can be whopper: a single graph edge missing, or between the wrong vertices, or with the wrong adornments can have huge implications.
For example, large amounts of work that have to be redone, or a project abandoned, or a mess that takes 10x longer than it should to write, and 10x the tech debt going forward with a bad architecture, or a fundamental security flaw.
One of the mistakes many people make is treating formalized diagrams as "marketecture" visuals, like they only need for handwaving sales presentation slides, where there's some kind of visual for every concept they want to be able to literally point to.
Nope, if you have software engineers and domain experts communicating and reasoning about your system in only the fuzzy terms of sales/exec presentations, you're really stabbing yourself in the face.
karlgkk
Apropos of nothing, all of the major ai models have gotten really good at turning a pdf or document into uml
Not great, mind you. 80% of the way there still saves an hour of your time tho
throw_m239339
It's useful to convey architectures. The problem is that UML has been abused by some vendors that implemented bad software based on "Rapid UML Development" and it soured a lot of developers. Also it is very old java OO oriented. But Sequence diagrams are still in use.
firesteelrain
These diagrams make a lot of sense if you understand the symbols and the relationships plus aggregations. You can easily talk to them. I use these diagrams with non technical people all the time
alganet
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, perfect UML is disposable. Thinking of long term diagrams that serve as documentation is a mistake.
BerislavLopac
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/
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?”
andrewstuart
At one point it looked like working in corporate IT meant you’d have to learn Java and UML and the magic light left the forest and the little fairies and elves that made computing magical and happy and bright died.
Fortunately UML was not the future.