Domain Driven Design Precise Aggregate Definition

Question

Aggregate

An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. The Aggregate is demarcated by a boundary which separates the objects inside from those outside. Each Aggregate has one root. The root is an Entity, and it is the only object accessible from outside.

In reading the book DDD Quickly, this was the proposed definition of aggregate. However, as I was parsing through some videos on youtube, specifically:

DDD & REST - Domain Driven APIs for the web - Oliver Gierke

He defined aggregate as follows:

Entity + Repository = Aggretate

He also recommended that we subclass string for each attribute, which I thought was counter conducive to DDD's objective of tackling complexity. What if we have 100 attribues?

My question therefore I suppose is twofold. Is a Repository part of an aggregate, or simply a vehicle by which the aggregate is persisted that belongs to the infrastructure layer? Second, is it prudent to increase the complexity and maintainability of software to achieve readability, or is this counter conducive to the goal of DDD, as a whole?

Answer 1

Is a Repository part of an aggregate

No, completely separate

a vehicle by which the aggregate is persisted that belongs to the infrastructure layer?

Not quite this either.

The primary role of the repository is that it acts as a boundary between the application and the data. The original discussion of repositories in the blue book introduced repositories with collection semantics; the interface for the repository was the same that you would use if the data were simply being stored in an in memory collection.

Second, is it prudent to increase the complexity and maintainability of software to achieve readability, or is this counter conducive to the goal of DDD, as a whole?

Not "readability", so much as "communication"; see chapter 2 of the blue book

On a project without a common language, developers have to translate for domain experts.... Translation muddles concepts, which leads to destructive refactoring of code.... A project faces serious problems when its language is fractured....

The complexity, in this case, is complexity drawn from the domain -- we probably shouldn't be imagining that we can model a domain with a thousand subtly different concepts using one or two domain agnostic abstractions.

are you stating that you believe that sub-classing string for mere readability, despite the fact that it could result in hundreds of additional classes would be a prudent approach, given it would serve as a catalyst for common language

Certainly not subclassing, no. But I would advocate having a unique name (in code) for each of the unique concepts (in the domain), even when those concepts share common representations.

To choose a naive example, Time isn't Money, even in those cases where the underlying representation of both is a long.

Scott Wlaschin's Domain Modeling Made Functional includes an extended example. At one point, he models verified email address and unverified email address as explicitly different from one another; even though those both have underlying string representations, he still takes the step of creating a single case union type for each of them, to capture in code the fact that these two concepts are not substitutes for each other.

That "complexity" is really just aligning the code artifacts with the ubiquitous language of the domain experts.

Now, depending on which Blub you are coding in, there may be additional complexity in your code artifacts to create these distinct names; as Scott demonstrates, it's really straight forward in F#, but it may not be so straight forward in your usual working language. My feeling is that if your choice of language is introducing complexity in your modeling, then maybe you should first be looking to see if there is another language better suited to the task.

Answer 2

An aggregate is all about the domain: It represents what is subject-specific for the given area of expertise.

In contrast, a repository is a technical thing that cares about persistence. So, the repository does not belong to the domain, it's a utility for being able to use aggregates.

So, no, the repository does not belong to the aggregate. You might also be interested in this question for details on this.

Regarding your second question: This dramatically depends on your application, and on the programming language you use… if you use a dynamically typed language such as JavaScript, you can still do DDD, but you won't be able to subclass things (leaving ES2015 class keyword aside, as it does not bring real object-oriented programming to ES).

Apart from that, DDD is a way to model a domain, and to allow interdisciplinary teams to communicate better about this domain. It is not about technology (unless, of course, your domain actually is technology ;-)).

Since subclassing is a technical problem, it is not related to DDD. If at all, it's related on how to implement a model that was created using DDD, but this is independent of DDD itself.

You might be interested in Modeling with your team from the wolkenkit documentation, which describes a way how to do DDD, and what to watch out for.

Please note that I am one of the authors of wolkenkit, a CQRS and event-sourcing framework for Node.js and JavaScript. So please take the last paragraph with a grain of salt.