Skip to content

Analysis Model

The Analysis Model bridges the gap between the real-world domain and the software implementation. It acts as a layer of abstraction, capturing the core concepts and behaviors of the domain without getting bogged down in technological details.

Incorporating the Analysis Model provides a structured approach to understanding and modeling the domain, ensuring that all stakeholders have a common language and a shared understanding of the system being built.

Ubiquitous Language in Action

The Analysis Model is developed collaboratively by domain experts and developers. It is one of the artifacts that make up the ubiquitous language of the domain. The model ensures the business and engineering teams are aligned on the domain's terminology, concepts, and behaviors. The Analysis Model translates this shared understanding into a technical representation using DDD's tactical patterns (like Aggregates, Entities, Value Objects, and Repositories), thereby serving as a blueprint for the system's design and implementation.

Standalone and Technology-Agnostic

The Analysis Model should remain independent of implementation aspects such as specific technologies and infrastructure choices. This focus on capturing the essence of the domain, rather than the details of its implementation, makes the Analysis Model a standalone artifact with several benefits:

  • Flexibility: The technology landscape is constantly evolving. Keeping the Analysis Model independent allows you to adapt the implementation to new technologies or platforms without altering the core domain understanding.
  • Reusability: A well-defined Analysis Model becomes a reusable asset. It can be a foundation for building multiple applications within the same domain, even when using different technical stacks.
  • Clear Communication: The technology-agnostic nature of the model fosters clear communication between stakeholders. Domain experts can focus on discussing business functionalities, while developers can translate those functionalities into code, bridging the gap between business needs and technological implementation without getting lost in technology-specific jargon.

Analysis Model vs. Code Model

The analysis model is a conceptual artifact -- diagrams, documents, and conversations that capture the team's understanding of the domain. The code model is the working software that implements that understanding in classes, methods, and tests.

In practice, these two models tend to drift apart. The analysis model is created at the start of a project and then left behind as the code evolves under the pressure of deadlines, new requirements, and technical constraints. Over time, the code model develops its own vocabulary and structure that no longer matches what the domain experts described. The gap becomes a source of bugs, miscommunication, and costly rework.

DDD's central goal is to keep these two models aligned. The code should be a direct expression of the analysis model. When the analysis model changes -- because the team learns something new about the domain -- the code is refactored to match. When the code reveals that the analysis model was wrong or incomplete, the analysis model is updated. Neither model is disposable; they evolve together.

How Protean Keeps Them Aligned

Protean's decorator-driven design makes domain elements explicit in code. An aggregate is declared with @domain.aggregate, a command with @domain.command, an event with @domain.event. These decorators name the elements in the ubiquitous language and make them visible in the codebase. When a domain expert asks "where is the Order aggregate?" a developer can point to a class with that exact name and role.

In-memory adapters enable immediate validation of domain logic without infrastructure dependencies. The analysis model can be expressed as working code and tested against real scenarios the same day it is discussed. This tight feedback loop catches misunderstandings early, before they are buried under layers of infrastructure.

When the analysis model evolves -- a concept is renamed, split, or restructured -- the code is refactored to match. Because domain elements are explicitly declared, the refactoring is mechanical: rename the class, update the decorator, adjust the references. The cost of keeping the models aligned stays low throughout the life of the project.

100% Testable

The Analysis Model should be designed to be testable in isolation from the final software implementation. This enables early and frequent verification of the domain logic captured in the model, ensuring its integrity and correctness before full-scale development begins.

By keeping the Analysis Model independent of underlying technology, it becomes 100% testable using plain old Python objects. This eliminates the need for mocking or performing dependency injection of external systems, allowing for straightforward validation of domain logic through unit testing. This approach not only accelerates development by identifying and addressing issues early but also enhances the maintainability of the codebase by ensuring that domain logic remains separate from infrastructure concerns.