Beyond DDD Building Blocks: Why You Need Archetypes

If you would like to see archetypes applied in practice, I maintain an open-source repository demonstrating archetypes implemented alongside Domain-Driven Design patterns: https://github.com/smalaca/archetypes

Have you ever looked at a complex system and felt that, despite having well-designed Aggregates and clearly defined Bounded Contexts, something was still missing?

We spend hours debating whether a concept is an Entity or a Value Object. We carefully define boundaries to keep our models clean. We follow Domain-Driven Design (DDD) principles to the letter. Yet when we zoom out, we often find ourselves reinventing the wheel in every new project. We struggle to maintain structural consistency across the enterprise, and our ubiquitous language frequently becomes a collection of localized dialects that do not communicate particularly well with one another.

The reality is that Aggregates, Entities, and Value Objects are the bricks of your architecture. They are essential, but they do not tell you how to build a cathedral. For that, you need blueprints.

You need Archetypes.

The Gap in the Building Blocks

The classic DDD building blocks focus on how to implement logic within a boundary. They provide a set of tactical patterns that help manage complexity and maintain consistency. However, they remain agnostic about the nature of the business concepts themselves.

An Aggregate can represent almost anything: a User, a Training Offer, an Order, or a Rule. From a purely tactical perspective, they all look similar—a cluster of objects with a root responsible for maintaining invariants.

In reality, however, a User and a Training Offer are fundamentally different kinds of business concepts. They follow different structural patterns and play different roles within the business ecosystem. When we ignore these higher-level patterns, we miss an opportunity to introduce a deeper level of order into our systems.

This is exactly where Business Archetypes become valuable.

Archetypes: The Missing Blueprints

Archetypes are recurring, high-level business patterns that transcend individual domains. Popularized by Jim Arlow and Ila Neustadt, they represent the fundamental shapes of business reality.

Think of archetypes such as Party, Product, Order, Inventory, or Rule. These are not merely labels. They are structural templates that describe how business concepts behave and how they relate to other concepts.

By identifying archetypes, we move from saying "this is an Aggregate" to saying "this is a Party playing a specific Role." That shift in perspective is significant. It allows us to leverage decades of collective business modeling experience and apply it directly to our software systems.

Seeing Archetypes in Code

Let's look at how this appears in a real implementation. In the Archetypes project, we do not rely solely on standard DDD annotations. We explicitly mark domain concepts with their corresponding archetypes.

Take a look at the User class:

@DomainDrivenDesign.AggregateRoot
@ArchetypeParty.Party
@ArchetypeParty.Person
public class User {
    private final UserId userId;
    private final Login login;
    // ...
}

At first glance, it is simply a User Aggregate. However, the @ArchetypeParty.Party and @ArchetypeParty.Person annotations reveal much more. They indicate that this class follows the Party archetype and specifically represents a Person.

This immediately tells us something about the model. We can reasonably expect such a concept to play various roles, such as Trainer or Student, and to participate in relationships commonly associated with people, such as addresses or contact information.

Now consider a TrainingOffer:

@DomainDrivenDesign.AggregateRoot
@ArchetypeProduct.ProductType
public class TrainingOffer {
    private final TrainingOfferId trainingOfferId;
    private final TrainingOfferName name;

    @ArchetypeProduct.ProductFeatureType
    private final Set<DeliveryMode> supportedDeliveryModes;
    // ...
}

Here, TrainingOffer is not merely an Aggregate. It is a Product Type.

That distinction matters. It tells us this concept defines a product rather than representing a specific instance of one. It contains Product Feature Types such as delivery modes. The structure immediately clarifies the model and helps prevent a common mistake: mixing catalog definitions with actual training deliveries.

Why Should You Care?

Archetypes do not replace DDD. They complement it by introducing a higher level of abstraction that provides several practical benefits:

1. Accelerated Modeling - You no longer start from a blank slate. Proven business patterns provide a strong structural foundation.
2. Structural Consistency - When teams across the enterprise share the same understanding of concepts such as Party or Product, models become more predictable and easier to integrate.
3. Clearer Ubiquitous Language - Archetypes establish a shared vocabulary that connects business understanding with technical implementation.
4. Resilience to Change - Models grounded in fundamental business patterns are more stable and less likely to be disrupted by every new requirement.

Summary

Aggregates and Entities are implementation tools.
Archetypes are modeling tools.

If you focus exclusively on tactical building blocks, you can still build a successful system. However, it will often be harder to understand, align, and evolve than necessary. Archetypes help you align your architecture with the deeper structure of the business itself.

The result is not only better software design but also greater consistency across teams, domains, and systems.

Are you ready to look beyond the building blocks?