Domain-Models wie Wörterbücher

A "domain model" visually represents the Who describing your product. The domain model is a dictionary that shows relationships between people and systems and abstract ideas. It offers a useful way to spot patterns, errors and omissions.

Domain models help you break-down ambiguity. They become the dictionary we use to express more complex ideas, such as workflows.

The domain model shows the Welche of our new product; these are the physical and abstract nouns we identified in our stream of consciousness exercise.

[Technical note: Domain modeling is also used to represent relationships between classes in object-oriented programming. The domain modeling described here is a more general relationship between physical and abstract objects, which may or may not be represented as classes in the final code.]

We use a "Has A" relationship to show aggregation, that one part belongs to another; und, an "Is A" relationship to show generalization, that one part is a specialization of another. In this way, we can visually represent through boxes and lines the same information that is present in 10s of pages of writing. You will see these relationships in the diagrams below, wo "Has A" is represented by a diamond-ended line and "Is A" by an arrow.

Pencil and paper is the preferred way to create simple domain models if you are just starting out. As your needs become more sophisticated, specialized UML software such as Enterprise Architect from Sparx Systems becomes a useful (but over complex) tool.

Let's explore some examples using SOFIns, my most recent venture.

Simple Example

In my SOFIns service, a Control Agent is a piece of software that allows special access to remote computers. SOFIns is a complex software system. It is very important that I describe it using consistent terminology and that this terminology is easy to understand by my developers. Here is how one part of it works, written out in a mouthful:

This same design can be represented visually through a symmetrical domain model that shows that Shared und Foreign agents are a specialization of a Control Agent and that Recipient, Owner and Sender are all specializations of a Benutzer. Reading the model, we can see:

• User has a Control Agent
• Recipient is a User
• Recipient has a Foreign Agent; und, Foreign Agent is a Control Agent.

SOFIns Domain Model for Agents and Users.

What is simpler to understand, the textual representation of Users and Control Agents described in the yellow box above or an illustration that has symmetry? You may not understand the technical system I built, but you can identify the simpler representation of the same Welche relationships.

Realistic Example

My SOFIns service is able to take control of a remote computer, even when that computer does not have an operating system installed or functioning hard disk drives. There are many parts involved in achieving this technical feat. It is very important that I describe Workflows using consistent, well defined terms. It is equally important that my developers understand these terms.

Here is how I defined the physical and abstract objects (die Welche of my service). This diagram started as a simple relationship between four major components and evolved as more specialized objects were identified in the course of refining the workflows.

The diagram below is anything but ambiguous. Complex? Ja. Ambiguous, no.

SOFIns Subsystem Showing "Component A" Objects