Skip to Content

Domain Modeling

In software engineering, requirements analysis is all about figuring out what the problem is that you are going to build software to solve. When properly done, it is completely separate from making decisions on how the software will solve the problem (which is design).

Part of understanding the problem is understanding the concepts and their relationships in the problem domain. Domain Modeling is a way to do this. It is essentially one exercise in Object Oriented Analysis (OOA).

UML Class Diagrams

UML class diagrams are a good notation for capturing concepts and their relationships. Important: a class diagram can be used to capture requirements (a domain model) or can be used to capture software design, but a single diagram should never try to do both. Know which the diagram you are looking at (or creating) is doing!

Creating a Domain Model in UML

Creating a domain model is fundamentally an exercise in thinking about your problem domain and writing down a formal description – a model – of the entities in your problem domain, and their attributes and relationships.

The best modern modeling notation to do this in is the UML class diagram. Since UML has notation that also supports program class design, we have to follow some rules when using UML class diagrams for problem domain modeling. These are:

  1. Classes represent domain entities; generally these are the important nouns in your problem domain language, such as Customer; class names, of course, are always singular.
  2. Class attributes represent attributes of those problem domain entities; these are not just programming-needed data fields, but all of the attributes necessary to understand the entity; attributes are often less-independent nouns in the problem domain language, such as a customer’s name.
  3. Class attributes should not be decorated with modifiers, and usually not even given a type. Modifiers and types are program design decisions, not problem domain concepts.
  4. You should not define any class operations in a UML domain model. Operations are not appropriate for a problem domain model, they are only appropriate for program class designs.
  5. Generic associations (plain line connectors) represent relationships between entities (classes); they must be named and have cardinality; they should not have arrows, since we are not designing any access direction; associations often come from verbs in the problem domain, but not always. For example, “a customer buys products” indicates an association between Customer and Product that is named “buys” and is one-to-many in cardinality (although further problem analysis and thinking may change that).
  6. Inheritance (generalization) and composition should be used where appropriate; aggregation is a “modeling placebo”, some like it and some do not; more complex connectors, such as interface connectors, do not belong in a domain model; if you see or think of an “is a” phrase in a problem domain description, this often indicates inheritance.
  7. Always remember that Object Oriented is about objects; the concept of a class is just shorthand for “this kind of object”; so think about domain objects when creating your domain model.

Cautions and Caveats

When doing Domain Modeling, there is no system. If you are tempted to put in a class named System or App or GUI or Window or anything in the system that you are going to build, stop! Domain Modeling is all about the problem domain’s information structure, not about designing your system or diagramming a user’s interaction with your system. It is also not about activity, so you are not trying to capture any functionality in your diagram. Arrows in a UML class diagram never represent activity or processing flow.

When creating a UML class diagram, either for Domain Modeling or Program Design, you must adhere to the official UML diagramming parts and their meaning. You cannot make up additional connectors or shapes or use existing ones for your own purposes. For example, the open right triangle arrowhead always means inheritance (generalization), so you cannot use it to mean anything else.

Helpful Resources

Dr. Barbara Ryder’s modeling slides are very good. She is a preeminent SE professor.

Some course lecture notes out of Germany

Another prof’s brief notes

Domain modeling, as presented above and by me, is different than the domain modeling talked about in Domain Driven Design (DDD), because DDD is centered on program design. However, both are centered on first understanding the problem domain entities and structure. Some DDD readings are:

A DDD post on Medium

DDD in MSDN

Martin Fowler’s DDD posts (various articles with DDD tags)

One DDD advocate’s blog

DDD proponents consider my view of a domain model an “Anemic Domain Model”:

Wikipedia:AnemicDomainModel

Martin Fowler on ADM

A DevIQ post on ADM

But others argue that an anemic model is good (I agree!):

ADM is SOLID

On Medium

Always remember that I am not presenting a design technique (as DDD is), but rather a requirements analysis technique. When doing requirements, you should not be thinking about design!

After you use domain modeling in your requirements analysis, then you can certainly use it in your program design, and this would give you a head start into DDD. Just never forget that you should strive to keep your thinking about requirements and design separate; do one at a time, don’t try to do both at the same time, and know when you are doing one, and when you are doing the other.