Table of Contents

1. Table of Contents
2. Introduction
3. ${domain.name} Domain
<#list domain.modules as module>
1. ${module.name}
<#if module.aggregates?size gt 0>
1. Aggregates
<#list module.aggregates as aggregate>
1. ${aggregate.name}
<#if module.services?size gt 0>
2. Services
<#list module.services as service>
1. ${service.name}
<#if module.domainProcesses?size gt 0>
3. Domain Processes
<#list module.domainProcesses as process>
1. ${process.name}
4. Ubiquitous Language

Introduction

This document describes ${domain.name} domain using concepts defined by Domain-Driven Design (DDD) methodology. It was generated directly from source code and can be considered as a close summary of what is actually implemented.

The following DDD elements are described in the remainder and shortly defined below. For more precise and complete definitions, please refer to the litterature:

• Value Object: an object fully described by its attributes and with no identity nor life-cycle,
• Entity: an object with a life-cycle and an identity;
• Aggregate: a group of related value objects and entities, one of which being called the root of the aggregate;
• Service: an object representing an operation that is not naturally part of a value object or an entity;
• Domain Event: an object representing an event and used to communicate information between aggregates potentially located in different bounded contexts;
• Modules: they describe boundaries inside of which each component has a unique name and a given definition. Some concepts might appear in different modules with the same name but with a slightly or completely different definition.

The identity of an entity is generally represented by a special value object called the key. An aggregate is identified by its root's key.

An additional non-DDD component is also described in next sections: the Domain Process. Domain processes are responsible for calling commands on aggregates (and therefore, starting transactions when necessary). Expect for some commands initiating a process, most of them are called when handling a Domain Event.

The following conventions are being used:

• As this document is generated directly from code, the domain is described by a set of modules. Each module is composed of a set of aggregates, services and domain processes.
• An undirected graph representing a module is composed of boxes representing the aggregates. Edges represent relations between aggregates i.e. the fact that one aggregate makes reference to another one.
• Value objects and entities are presented in the context of their aggregate. An undirected graph representing an aggregate is composed of boxes (Entities) and ellipses (Value Objects). The aggregate root has thicker borders. Edges represent relations between the different components. Dashed edges represent a reference made to another aggregate via a Value Object (the key of the aggregate root). Dashed edges represent the relations shown in module graph.
• Domain processes are represented using directed graphs, each node being a step of the process. Entering a step of a domain process generally implies the creation of a new aggregate or the update of an existing one. External steps (i.e. steps executed outside of the process) are represented as dashed boxes. Edges are labeled with the name of the domain event which implies the transition from one node to another.

The rest of the document is split in two parts:

1. the description of the different modules and their components,
2. the ubiquitous language, presented in the form of a glossary. Each entry is composed of a name, the module (if relevant), the type of component and a short description.

${domain.name} Domain

${module.name}

Aggregates

${aggregate.name}

Value Objects

<#list aggregate.valueObjects as valueObject>
• ${valueObject.name}: ${valueObject.description}

Entities

<#list aggregate.entities as entity>
• ${entity.name}: ${entity.description}

Relations

Events

Services

${service.name}

Domain Processes

${process.name}

<#list process.steps as step>
• ${step.name}: ${step.description}

Ubiquitous Language

<#list ubiquitousLanguage as entry>
1. ${entry.name}, ${entry.type}, ${entry.description}