How to create big aggregates in DDD
Tags: discuss, ddd, aggregate, domain
Published: 2022-05-10 13:29:50

---
title: How to create big aggregates in DDD
published: true
description: Are you familiar with DDD? Are you using it in your work? I am! I have been reading about DDD about quite some time and I think it's great, but I have some doubts that are not covered in the blue book/some articles I've read. For that reason, I'm going to expose my problem here where it can be discussed in the community.
tags: discussion, ddd, aggregate, domain
cover_image: https://ychef.files.bbci.co.uk/1600x900/p07n19vr.webp
---

Hi! My name is Antonio and I have been reading about DDD for quite some time. I think Domain Driven Design is the right tool for some enterprise applications, so recently I have been trying to use it on my company. 

Before continuing reading, I'm assuming you have a good knowledge about DDD and related concepts (sorry for not including an introduction, but I think there are already too many introductory articles about DDD, so I don't feel like writing another one).

## Problem

So, what problem am I facing with DDD? **Big aggregates implementation** (emphasis on implementation and not design).  When I say big, I do not mean they contain a lot of different entities or a lot of dependencies, but many instances of the same entity. For example, a bank account aggregate has one child entity: a transaction. Now, that bank aggregate can have hundreds or thousands instances of that entity. 

Let's suppose that my company domain is about `Roads` and `Stops` (this is just an example). Both things are entities because they have an identity. In this case, `Road` would be the root aggregate and `Stop` would be a child entity of that aggregate. Let's say they have two or three fields each, it does not really matter. Here is a quick implementation of that model in Python (I have not used dataclasses and a lot of the logic is missing because it's not important for this discussion):

```python
class Road:
    id: int
    name: str
    stops: [Stop]
    ...

class Stop:
    id: int
    latitude: int
    longitude: int
    ...
```

So now, you need to create a repository to retrieve those entities from storage. That's easy enough, just a couple of SQL queries or reading a file or whatever you want to choose. Let's suppose this is our repository (let's avoid interfaces, dependency injection and so on because it's not relevant in this case):

```python

class RoadRepository:
     def get(id: int) -> Road:
         ...
     def save(road: Road) -> None:
         ...
```

Easy enough, right? Okay, let's continue implementing our model. The `get` method is really easy, but the `save` method has a lot of hidden complexity. Let's suppose we are using a relational database like `postgres` to store our entities. Let's say we have two tables: `roads` and `stops` and they have a relationship and so on.

In order to implement the `save` method, we would need to update all of our child entities. **And that's the problem**.  What happens if our `Road` instance has 345 different stops? How do we update them? I have not a final answer for that, but I have some proposals!

### Solution 1

This would be the equivalent of solving the problem by brute force: delete everything and recreate it again. 

#### Props

- Easy to implement

#### Cons

- Not sure about the efficiency of this one. but I estimate is not that good. 
- If you set the unique identifiers on the database level, you are going to have a problem keeping the same identifiers.

### Solution 2

Keep track of all the changes at the aggregate level. Something like this:

```python
class Road:
    id: int
    name: str
    stops: [Stop]
    
    def update_stop(self, stop: Stop):
        ... some logic to update the list ...
        self._changes.append({
           'type': 'UPDATE',
           'stop': stop,
        })
```

Then we would read that list of changes on the repository and apply them individually (or in bulk, depending on the change type, for instance, we can group together the deletions, creations, etc.).

#### Props

- It's more efficient than the first solution because in average requires less db operations.

#### Cons

- Our domain has been contaminated with logic not related to the business.
- A lot of code is necessary to keep track of the changes.

### Time to discuss!

What do you think about this problem? Have you faced it before? Do you have any additional solutions? Please comment it and we can discuss it :)