Hacker News

UML diagram for the DDD example in Evans' book

2025-04-1819:4012175github.com

UML diagram for the DDD example—a cargo shipping system—from Eric Evans' book - takaakit/uml-diagram-for-ddd-example-in-evans-book

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.

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.

*2: To create this directed graph on your own, Astah Professional/UML and the m+ plug-in are required.

  • Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2004.
  • Evans, Eric. Domain-Driven design Reference: Definitions and pattern summaries. Dog Ear Publishing, 2014.

Diagram map (diagram_map.html) and Directed graph (directed_graph.html) include the following libraries:

Files and data in this project other than the above libraries are under the Creative Commons Zero (CC0) license.

If you spot any mistakes in the diagrams or model, please open an issue.


Read the original article

takaakit

Karma: 66
...
 @Hacker__News
@hacker._news

Comments

  • By neilv 2025-04-1821:014 reply

    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.

    • By tinco 2025-04-199:032 reply

      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 this increasingly burdensome complexity that we were not reaping any rewards of. Then one day we had enough and a colleague redesigned the system to ditch the extra complexity resulting in a much more elegant design that was easier to reason about.

      That bliss continued for less than a year, until some customers asked for a particular report that we needed to generate based on a structure of the information that was now no longer present. We had to redesign it again, migrating was super painful and involved a temporary workaround that basically involved an extra branch on literally every piece of code that touched the inspection system.

      In retrospect, I still don't know how I could have convinced the team that the complexity was something we needed when no customer required it for 3 years. Especially when the colleagues who took over that system from me had gained much more experience and expertise in the domain than I had since I had designed the original.

      It would probably have been better if I had recorded the requirement that prompted the complexity, but had not actually implemented it as no customer had actual need for it at the time. Then we would not have had to deal with the complexity the first three years, and then evolved the product when the need arose.

      • By molf 2025-04-199:34

        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.

      • By neilv 2025-04-1917:53

        Thinking aloud here...

        I like your idea of capturing some requirement(s) that motivated the extra complexity, and retaining those requirements in a place they'll be seen and consulted when any new release planning and architecture happens.

        This seems related something I do when scoping an MVP or release: work through the requirements breakdown, and mark the things we considered but decided not to do in that release (the "NON-Reqs"). Keeping them in the document gets everyone who looks at it up to speed, so we don't keep rehashing, and also makes it very clear to people that this thing someone told them the system would do is definitely not happening (a very-very-very common miscommunication in some companies).

        But if a NON-Reqs suggests some future growth affordances that I think are important to try to include in the new architecture work now, to avoid/reduce very expensive refactoring/rewrites/rearchitecture in the near future, maybe some of those NON-Reqs should be moved to bulletpoints in a requirements section like "Architecture Growth Affordances", and become medium-priority requirements not to preclude in the architecture. Where it can be triaged, prioritized, and traced like any other requirements.

        I like that idea a bit, but a few problems:

        * Someone might get confused that you're promising to deliver that in a future release.

        * Someone might blame if, when the future release planning comes, you say that feature will take a lot of work, but they thought you already did most of the work for it in the previous release.

        * You'll need everyone involved to find the right balance of how much to think about about this release, and how much to keep in mind ability to do future releases. By default, people will have a lot of trouble with both kinds of thinking.

        * A lot of these architectural decisions with growth in mind will happen after the requirements are locked in, and making frequent changes to that set of requirements is a very confusing precedent to set. (For example, most people won't take the commitment to the requirements seriously, if they think things can just be tossed into it later as needed, or if they think you're just doing incompetent theatre. You want them to get the idea "anything that isn't committed to in the requirements, isn't happening in the release; so everyone think and agree hard together now, so that we'll all be working effectively and efficiently towards the same viable release". Only after everyone gets that, do you introduce the flexibility.)

        Maybe those requirements should go to a place for "anticipated future requirements" (but that isn't only a backlog of "candidate requirements"), in that it can be referenced for traceability when you make an architectural decision with future options in mind?

        Or, the fallback (which I've used countless times) is to document with the architecture (embedded in the code, or in other canonical arch docs) the rationale for the decisions. Then, when someone goes to change the architecture, that information is hopefully somewhere they'll see. (This assumes that the person changing the architecture is a smart professional.)

    • By motorest 2025-04-1919:43

      > 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.

    • By pydry 2025-04-1911:44

      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.

    • By mdaniel 2025-04-192:374 reply

      > 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

      • By rapnie 2025-04-1910:58

        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

      • By serial_dev 2025-04-1912:091 reply

        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.

        • By takaakit 2025-04-1913:16

          I also think it's bad to create this many diagrams at this level of detail, or try to keep the model updated, in an active software project. I think it's important to be selective—sometimes that even means choosing not to choose.

      • By RealityVoid 2025-04-195:451 reply

        > 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).

        • By motorest 2025-04-1919:55

          > 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.

      • By takaakit 2025-04-193:45

        This directed graph is automatically generated by the plugin based on the UML structural elements (classifiers and relationships). Hope this helps.

  • By alganet 2025-04-1823:072 reply

    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.

    • By bartvk 2025-04-196:181 reply

      I very much like your comment. It describes practical use of diagrams. In the past, I've included diagrams for a particularly complex state in the comment on top of my code. It certainly doesn't describe the whole system, or even the complete state of that code. And I expect that someone will delete the comment at some point. That's all fine.

      • By alganet 2025-04-1912:39

        Thanks!

        I remembered once I drew ASCII diagrams for a particularly tricky algorithm in the top of its unit test methods. And people indeed deleted them.

    • By teeray 2025-04-1911:501 reply

      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.

      • By motorest 2025-04-1919:571 reply

        > 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?

        • By teeray 2025-04-1920:23

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

  • By ak_111 2025-04-1820:3617 reply

    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?

    • By dwaite 2025-04-197:11

      Underneath the good ideas of UML was the idea of model driven development - that you could generate code from the models.

      Good diagrams are an art form though, just like other forms of good documentation. There is a big difference between a diagram being a normative source of truth, and being a good tool.

      Take this diagram as an example: https://takaakit.github.io/uml-diagram-for-ddd-example-in-ev...

      * Nearly the top half is taken up by relations which aren't especially helpful, and would be better expressed on the entities themselves.

      * The "Location" type looks like the primary type in the system based on nearly half the types in the system connecting with it, creating a nest of graph edges. However, this is likely a simple and immutable record type. If the entities in this diagram had attributes (e.g. like a class diagram), you could refer to it by name, and greatly simplify the cognitive load in understanding this picture.

      This is the sort of diagram that gets generated from code, and is at the level of specificity needed to generate code from a diagram. It also isn't very useful for using the model to convey the system to a person - a developer might be more comfortable reading the code rather than looking at a picture generated from it.

      IMHO, that split focus in UML between people and tooling greatly reduced the overall usefulness and understanding of the system. It gave UML a bad reputation. Training on MDD tools prevailed over providing a baseline of common nomenclature to enable "team cave drawing on a whiteboard", which has no commercial tooling or market other than the whiteboard and markers.

      The areas where visual languages have a bit more prevalence are on the business modeling side, including things like network architecture diagrams.

      It is a bit of a shame - going through a set of use cases while iteratively improving the architecture by improving a set of class, sequence and ECB diagrams is something I always found to be crazy efficient vs diving immediately down to prototype code.

    • By dcminter 2025-04-1820:592 reply

      I'm kind of hazy about where the boundaries between bona fide UML and PlantUML are, but PlantUML is in pretty common use in my world - more for sequence diagrams and state diagrams than class diagrams though. Of course PlantUML has competition from things like Mermaid, but they're all much of a muchness.

      My very non-scientific impression is that tools like Rational were mostly used for drawing class diagrams and ... that just turned out not to be that useful because the tooling didn't exist to round-trip changes in the code back into the diagrams meaning the diagrams lost parity with the code rather quickly. It was sort of useful in the linear design/code/deliver world, but we're a lot more iterative now.

      • By afpx 2025-04-1823:401 reply

        I remember having to use Rational Rose back in the day, and I had to ask my boss why because the software crashed and the files got corrupted all of the time. If it didn’t help them write better software, why were we using it?

        That said, I still find plantuml to be helpful, particularly for sequence and activity diagrams. With LLMs especially. Use dependency injection, fine granularity components, sequence and activity flows. At least for me, helps keep my mind organized. But, these days I work alone. I feel it may be too dated for the modern developer.

        • By DaiPlusPlus 2025-04-192:37

          > With LLMs especially...

          > I feel it may be too dated for the modern developer.

          Sounds like you're still ahead of the curve, worry not.

          I'm still too much of a curmudgeon to even give LLMs a try.

      • By nickthegreek 2025-04-1821:081 reply

        I just learned about UML earlier today when I wanted to bring in a mermaid flowchart into lucidchart. If you bring in mermaid using lucidchart, it makes it a raster image. But if you use UML markup, you can ungroup it and modify. I couldn’t get a good way to convert from mermaid to UML markup that lucidchart could handle. Ended up a dead end for me.

        • By dcminter 2025-04-1821:53

          On a similar note I've had various annoyances with wanting to round trip diagrams from Mermaid or PlantUML into Miro and vice versa. There doesn't seem to be much out there to facilitate this, which is strange, because it feels like a very enterprisey thing to want to do.

          There's probably a SaaS product in it for someone sufficiently interested in the topic... probably not at unicorn scale, but enough for a side income perhaps?

    • By elric 2025-04-196:18

      It's still being taught in schools AFAIK.

      Had an intern a year ago whose school forced them to go the whole nine yards with UML. Our company gave them a project to build, and their school made them draw use-case diagrams, class diagrams, sequence diagrams, and activity diagrams, before the student was allowed to write any code.

      This was a waste of everyone's time, and we gave the school some choice feedback which I'm sure they'll ignore.

      Sequence diagrams are still used quite a lot, and for good reason, they're incredibly useful. I see simple class diagrams quite frequently as well, but without the poorly designed arrow nonsense (shaded? open? closed? argh!).

    • By whartung 2025-04-1821:502 reply

      I think folks upgraded to GML [0]

      [0] https://wiki.c2.com/?GalacticModelingLanguage

      • By icedchai 2025-04-1822:55

        I love it. Even with GML, you run into problems. Diagramming is an art more than a science. You have to know your audience (technical people, marketing types, investors, customers...)

        Leaving stuff out is also important. (Example: Unless you're building a DNS related product, don't bother to include "DNS" in your diagrams. Your use of it is assumed.)

      • By oleggromov 2025-04-1822:261 reply

        This is wonderful. Thank you.

        • By smcameron 2025-04-1911:07

          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

    • By zabzonk 2025-04-1820:432 reply

      Just my opinion, but I think that folks realised it was not much use for initial design, but could work reasonably well for documentation of existing systems.

      • By devenson 2025-04-1821:36

        Documenting existing system dependencies using the product which which I'm a founder:

        https://schematix.com/video/depmap

        Like UML deployment diagrams, but our models are interactive and can be queried.

        We also have a large customer doing DDD modeling and then generating code directly from the models they build.

      • By alganet 2025-04-192:26

        Yeah, it started to work for documentation when they invented that thing that prevents you from having to constantly maintain super complex diagrams in order to keep them in sync with the actual product.

    • By ohgr 2025-04-1823:03

      UML never matched reality and this isn’t really an engineering discipline even if we pretend it is.

      You can really break UML by specifying a system then changing it a number of times. That process will hurt you. Badly.

    • By globalise83 2025-04-196:54

      In payments and most other industries with a lot of connections to 3rd parties and complicated transactional flows, UML diagrams (especially sequence diagrams) are used a lot, albeit mostly as a conceptual tool rather than some formal description (see for example the Stripe docs). I also see UML state chart-like approaches being used more formally in frontend (e.g. XState).

    • By riffraff 2025-04-1820:462 reply

      UML as a methodology seems to have disappeared, but bits of it (e.g. sequence diagrams) seem to have been absorbed by the profession at large.

      • By billfruit 2025-04-198:22

        I think the UML statecharts are a much more useful diagrams than sequence diagrams. It can convey a lot more of the behaviour especially if you use the entire 'Harel' formalisms.

        Too bad, they aren't that popular to document behaviour, because sequence diagrams really don't convey that much.

        For example timeouts are very neatly described in a harel state chart. How will one describe timeout and timeout handling in sequence diagrams.

      • By SanjayMehta 2025-04-190:492 reply

        Sequence diagrams existed prior to UML. They were extensively used in telecom: “message sequence charts.”

        They were part of a telecom language called SDL. There were tools to “compile” to various languages such as C. If you followed their rules, you were supposed to be able to go back and forth between C and SDL.

        I only remember this because the biggest tool provider at that time was a French company called Verilog. They preceded the HDL by a few years, I guess.

        • By dilyevsky 2025-04-194:22

          I used to work for Motorola's telecom division and we used IBM Rational Suite to generate C++ classes from the SDL. Merges (and we used very long-lived release branches) were pure hell...

        • By leoc 2025-04-192:421 reply

          IIRC sequence diagrams were invented by one of Carl Hewitt’s PhD students during Hewitt’s earlyish work on the Actor model?

    • By codethief 2025-04-193:00

      IIRC it got a bit out of fashion towards the end of the 2000s along with the OOP fanatism it was closely related to.

    • By pjmlp 2025-04-1913:38

      Just this week I did a bunch of UML diagrams.

      It is pretty much alive in big corps.

      I imagine it got out favour on hipster coffee shops coding their next big idea, rewriting multiple times, instead of validating their ideas in first place.

      Github supports UML diagrams in their markdown for a reason.

    • By hirvi74 2025-04-191:011 reply

      My theory is that Agile killed it. UML requires a lot of planning up front, and in my unfortunate experience, any sort of planning is completely antithetical to Agile.

      • By 4b11b4 2025-04-191:14

        Experiencing this right now, zero planning for a re-write of a system

    • By ChrisMarshallNY 2025-04-192:31

      I occasionally use a “UML Lite,”[0] to illustrate stuff, but I seldom work at the scale that I would consider it necessary. I generally keep my designs in my head. Makes for much faster, and higher-quality work.

      [0] https://littlegreenviper.com/the-curious-case-of-the-protoco...

    • By ramon156 2025-04-1820:482 reply

      We still learned UML diagrams in school in 2019, though I have to say I haven't used it anywhere in my job

      • By neilv 2025-04-1821:10

        In the case of UML, I think enterprise consulting and tool sales might've already obscured much of the real value of semiformal methods, before a CS curriculum could sour students on it.

        With ZIRP growth scheme startups hopefully over, and more of us having to get jobs building systems that work reliably and sustainably, we might gain a new appreciation for system modeling.

    • By titaphraz 2025-04-1821:572 reply

      UML was a scam really. They took a lot of very useful diagrams and created a absolute behemoth of unproven system to develop software and sold it.

      The diagrams are very nice and useful. But the UML as a process, if taken literally, it a total disaster.

      • By hnb2137 2025-04-197:541 reply

        One of the creators of UML, Booch, has said so himself that it was taken to a point where it should never have. Interesting interview: https://youtu.be/u7WaC429YcU?feature=shared

        • By titaphraz 2025-04-1917:45

          Thanks. I was only going to find the part about UML but I ended listening to the whole thing. What a legend!

      • By hmartin 2025-04-1822:30

        > UML was a scam really.

        Objectively and utterly wrong.

    • By watsonjs 2025-04-195:011 reply

      I think its abandonment is related to the adoption of agile methodologies. UML was used to describe systems from day one. Agile methodologies came in, claiming that we don’t need it.

      • By PaulRobinson 2025-04-195:481 reply

        You still need to describe systems in agile.

        All agile does is ask you to iterate, which means updating your design, your code, and your tests & documentation, as you learn.

        Please read the agile manifesto again, and actually apply it. It does not say we don’t do design at all. Never did.

        • By pjmlp 2025-04-1913:45

          There is the manifesto, and then how almost everyone does it.

    • By andrewstuart 2025-04-1912:241 reply

      UML and waterfall/Big Requirements Up Front/analysis paralysis all ride in the same car.

      Agile and scrum and iteration saw them off.

      • By pjmlp 2025-04-1913:46

        And that is how we end doing integration tests where folks in the field discover missing user stories that no one is going to implement, because there is no budget left.

    • By NBJack 2025-04-1821:15

      Just another data point that the "low code/no code" revolution sputtered out over a decade ago.

      I still see and use a small subset of UML for more complex architecture discussions, but that's about it (i.e. service nesting, message passing, etc.).

HackerNews

About