My head hurts I've been reading about DDD for years and I've now decided to try it in as pure a form as possible. I'm really struggling in general to define aggregates, but this specific problem is worthy of a question here.

I have a system that is used by multiple clients. Clients can buy a number from me, but I need to buy numbers from my suppliers, so I have a pool of pre-purchased numbers that are available to my clients. When I add numbers into the pool I'm using an aggregate that brings together some of the system-specific data - buy when a client purchases a number it needs to work with their aggregate to add the number but also remove the number from the pool.

I'm trying to bring these both into the same transaction, but I also have an inkling that that's not the best solution here. So any help is appreciated!

  • What's the domain? It's really hard to talk about Domain Driven Design without understanding the domain. For example, if you have merchandise that customers can purchase, you need to pull that merchandise from your warehouse. You will have other systems in the supply chain management that will control how you replenish your stock in the inventory. In this case, your warehouse inventory is a domain object, and you have a couple of other systems that interact with that inventory. One being the customer sales side of things, and the other being the supply chain. Dec 23, 2019 at 18:46
  • It's as described :) telephone numbers. The system has a pool of them that the clients can buy and then be transferred to their account
    – Carl
    Dec 23, 2019 at 18:50
  • The need to obtain data from other sources is not new. What is it about DDD in general (and aggregates in particular) that is preventing you from doing that? Dec 23, 2019 at 18:51
  • To put it another way, how would you do this if you didn't have to deal with aggregates? Dec 23, 2019 at 21:01

1 Answer 1


Short answer: try modeling the number's customer instead of the customer's number.

A big part of domain modeling is digging into the domain language to discover entities that might not be obvious.

TelephoneNumber is probably an entity in your domain - it's a thing that has a life cycle. You acquire the rights to it from your supplier, you assign those rights to a customer, perhaps you reassign those rights to a different customer when the first is done with it? Maybe you release it back to the supplier, and so on.

The relationship between the customer and the phone number may also be an entity - again, we can model when that relationship begins, and when it ends, and perhaps other interesting events as well.

(One cheat is to think about a relational data model - if you have a table, you likely have an entity).

Having identified your entities, you can then start thinking about where the aggregate boundaries belong. It sounds like you have something like a "pool" that keeps track of how many numbers are available, and decides when we should be ordering more. So your modeling question is largely about whether the number assignment belongs with the customer, or with the pool, or standing alone on its own, or if everything belongs in one single aggregate.

Any of those can be the right answer, depending on how much risk is introduced by various data races, and how much benefit you can accrue by distributing the work.

But given that you don't appear to have discovered this on your own, I would suggest that you start with the idea of modeling a pool of numbers, and treat the assignment of numbers as something that happens within the pool "aggregate" to start with. It may not, in the end, be the best answer for your circumstances, but working that part of the problem is my best guess at getting you unstuck from your current condition.

I'm trying to bring these both into the same transaction, but I also have an inkling that that's not the best solution here.

When everything happens within a single relational database, you can be a bit sloppy about how you draw your aggregate boundaries. But when you start thinking about having more than one database... well, the fact of the matter is that transactions across multiple databases suck, so you want to align your domain model and your data model so that you don't ever need to make a change in more than one database at a time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.