Using UML for Domain-Driven Design

While it is definitely a lot less common to see people using Unified Modeling Language (UML) in software businesses these days, I believe it can be a valuable tool for planning and implementing Domain-Driven Design (DDD) principles. DDD is an approach to software development that focuses on understanding and modeling the problem domain, and UML provides a set of notations and diagrams that can assist in this process. Let’s delve into the reasons why it can be helpful.

• Visualize Domain Entities: UML helps you draw pictures of what your software’s world looks like, showing model domain entities, their attributes, and their relationships. You can use it to sketch out the things you care about, like customers, products, or orders. By identifying these entities, you can better map them to code structures.

• Define Aggregates: UML class diagrams are useful for defining aggregates and their boundaries. Aggregates are a key concept in DDD, and they represent a group of related entities that are treated as a single unit. Think of aggregates like a box of Lego. UML helps you draw lines around groups of these Lego and say, “This is one big thing.” Those are your aggregates.

• Value Objects, Not Identifiers: UML is great for showing things that don’t have their own names, like a payment amount or date of purchase. These are value objects, and UML makes it clear they’re part of a bigger entity.

• Modelling Services: UML can be used to model domain services and their interactions. When your software needs to do something, you can map out the steps using UML. UML sequence diagrams or activity diagrams can illustrate how domain services collaborate to accomplish specific tasks, and help showcase the flows.

• Defining Bounded Contexts: Bounded contexts help in segmenting the domain into distinct, isolated areas, each with its own language and models. Bounded contexts are like neighborhoods for your software. UML diagrams show how these neighborhoods stay separate but can chat with each other.

• Expressing Business Rules: UML allows you to add comments and notes to diagrams, which can be used to capture and express complex business rules and constraints. These comments serve as a valuable source of documentation for both developers and domain experts, helping to discover any issues earlier on.

• Mapping to Code: Once the domain model is well-defined in UML, it can serve as a blueprint for implementing the software. Developers can use the UML class diagrams as a reference for creating classes and relationships in the code, removing some of the ambiguity that is sometimes found when starting new features.

• Communication: UML diagrams can serve as a common language for communication between the developers and product owners. It helps everyone understand the project without getting lost in jargon.

• Handling Project Changes: As you learn more or when requirements change, you can easily update your diagrams. There is several tools available to create and manage your diagrams, making handling scope creep a breeze to incorpoate into planning.

Hopefully this makes you see how using UML for implementing DDD in your projects can be a positive, making the process a bit easier to manage along the way.

Update 2022-03-09: I’ve now written a post about using MermaidJS for diagrams and included some class diagrams to show how easy it is to do.