# Iterative Domain Modeling

**In short:** Iterative domain modeling means a domain model starts simple and improves over time. The team builds it in code, learns more about the domain, and revises model and code together.

## Explanation

A domain model describes the business area a software system serves. Teams often want to design it fully on paper first and build it afterward. Domain-Driven Design (see the article Domain-Driven Design) takes a different view. It evolves the model in software during the life of the product.

**Why the first model is not the final one.** Initial models are usually naive and superficial. They rest on shallow knowledge, so they need to be improved.

**How the model grows.** The team's understanding of the domain deepens, and the model and its shared language should change with it. See the article Ubiquitous Language. In one shipping example, months of work with domain experts and many iterations produced a quite different model from the starting one.

**Breakthroughs.** Repeated refactoring toward deeper insight can lead to a breakthrough. Chapter 8 of Evans's book tells such a project story. Refactoring means changing the structure of code step by step. See the article Refactoring.

**Model and code stay tied together.** Model-driven design stands on two legs: the model and its implementation in code. The two must be tied together. The team's language is based on the model used in the software. A project case shows this: as the team added domain logic, the code used more of the shared language.

## Example

A team builds a simple model of a clinic: a patient has appointments. They put it in code and release it. Later, talks with clinic staff show a different picture of the work. The team renames concepts, reshapes the code, and updates the shared vocabulary together. After several rounds, the model looks quite different from the first version, and the code still reads like the model.

## Trade-offs

The facts here do not cover costs or risks in detail. One point follows from them: the model only stays useful if the code keeps matching it. If model and code drift apart, the two legs of model-driven design no longer hold together.

The model is built, learned from, and refactored in a loop together with the code.

```mermaid
flowchart LR
  A[Naive model] --> B[Implement in code]
  B --> C[Learn with domain experts]
  C --> D[Refactor model and code]
  D --> B
  D -.-> E[Deeper model]
```

## Checks

- The documentation states that the domain model evolves as the team's understanding grows, rather than being fixed up front.
- The team's shared language is based on the domain model used in the software.
- The domain model is tied to its implementation in code.

## Related

- [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md)
- [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md)
- [Ubiquitous Language](https://arc.fuet.ch/concepts/domain-driven-design/ubiquitous-language.md)
- [Refactoring](https://arc.fuet.ch/concepts/fundamentals/refactoring.md)
- [Iterative and Incremental Development](https://arc.fuet.ch/concepts/fundamentals/iterative-and-incremental-development.md)
- [Cargo Shipping Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/cargo-shipping-domain-model-example.md)
- [Entity Life Cycle](https://arc.fuet.ch/concepts/domain-driven-design/entity-life-cycle.md)
- [Business Domain Understanding](https://arc.fuet.ch/concepts/domain-driven-design/business-domain-understanding.md)

## Sources

- [III](https://www.dddcommunity.org/wp-content/uploads/files/books/evans_pt03.pdf) — dddcommunity.org, accessed 2026-11-09
- [Domain Driven Design](https://martinfowler.com/bliki/DomainDrivenDesign.html) — martinfowler.com, accessed 2026-11-09
- [Refactoring to a Deeper Model - InfoQ](https://www.infoq.com/articles/refactoring-deeper-model/) — infoq.com, accessed 2026-11-09
- [Ubiquitous Language](https://martinfowler.com/bliki/UbiquitousLanguage.html) — martinfowler.com, accessed 2026-11-09