Skip to content
Software Architecture Guide

Deriving System Components from the Domain Model

Explanation

Section titled “Explanation”

A domain model describes the business concepts a system deals with. You can read it as a source of building blocks. Look at which concepts belong together, and group them.

Start from cohesion. arc42 says cohesion should be the main driver when forming building blocks. Cohesion means that the things inside one block belong together. See the article Coupling and Cohesion.

Look at the groupings the model already shows.

  • In the well-known cargo sample, Cargo is the central aggregate. An aggregate is a cluster of related objects handled as one unit. See the article Aggregate. The root of Cargo holds Delivery, Itinerary and Leg.
  • HandlingEvent is a domain event. It records a real-world happening, such as cargo being loaded or unloaded. It is the basis of the delivery history. See the article Domain Event.
  • Bounded contexts split a large domain model into parts, because one unified model is not feasible for a large system. They can be read as the major units of a system. See the article Bounded Context.

Give the use cases an owner. Application services such as BookingService support specific use cases. In the sample, such a service plays the orchestrating role of a booking application. It coordinates the other parts.

Separate own components from external systems. In the sample, external routing sits behind a wrapper. The wrapper translates to and from the other team’s API and data model. This keeps the outside system apart from your own components.

Map the result to arc42. The building block view is a hierarchy of black boxes and white boxes. A black box shows what a block does. A white box shows what is inside. Level 1 is the white box of the whole system. arc42 asks you to mark third-party elements clearly and to show them only exceptionally.

Example

Section titled “Example”

A small shop system has a domain model with orders, products and shipments. The team asks which concepts belong together. Orders and their lines form one cohesive block. Shipment tracking forms another. An order-entry service ties the use case “place an order” to both. The shop uses a payment provider run by another company. The team puts a translating wrapper in front of it and marks it as external in the building block view.

Trade-offs

Section titled “Trade-offs”

For larger systems, arc42 puts domain model elements in the crosscutting concepts chapter, not in the building block view. Many blocks refer to them, so listing them as blocks would mislead. See the article Crosscutting Concept.

Deriving blocks from the domain model also depends on the model. One unified model for a large system is not feasible, so you need several bounded contexts. Each context then gives its own candidate blocks.

Checks

Section titled “Checks”
  • Building blocks are grouped by cohesion, so things inside one block belong together.
  • Third-party or external elements are clearly marked in the building block view and shown only where needed.
  • External systems sit behind a translating wrapper that separates them from own components.
  • Domain model elements used by many blocks are described in the crosscutting concepts, not as blocks.
  • The building block view starts with a level 1 white box of the whole system.
Section titled “Related”

Sources

Section titled “Sources”