DDD concepts: Domain, Aggregate, Entity, Value object, Bounded context

  1. Should every aggregate be a single microservice and have a single DB ( since every microservice should have a single specific DB)?
  2. Entities = tables at the microservice DB?
  3. What are Value objects in terms of microservices architecture? (I know what is value object in terms of DDD and how it different from Entity though)
  • 1
    There's no easy answer to how these map (and in some ways the question doesn't even make sense), because DDD is not an architecture, it's an approach (that can be applied to microservices). The concept of the domain predates DDD and has the same meaning. A bounded context is an idea a lot of people get wrong, and the rest are common patterns that a) can be utilized in different ways, and b) you don't even have to use. Another problem is that the term microservices itself is somewhat imprecise (people may mean somewhat different things by it). So the question is fairly broad. Commented Sep 8, 2019 at 21:01

2 Answers 2


You try to map two orthogonal concepts:

  • The DDD concepts are used to design the domain objects and domain logic of your application;
  • Microservices is an architecture style that guides the distribution and deployability of an application's functionality.

SO there is no clear map between both.


The DDD aggregate says something about the structure of several related objects: they are tightly coupled. The only thing that is for sure is that objects of an aggregate shall not be handled by different microservices, since it would make them tightly coupled instead of promoting decoupling.

But that's all: a microservice, depending on the services to be provided, could need more than one aggregate to offer a useful service. And the question of shared database vs. database per microservice or even a mix between the two remains a choice of architectural pattern to be done independently of any DDD considerations.

Entity and tables

First, “tables” suppose that you''re using an RDBMS. NoSQL technologies may rely on something else than tables.

But if you're in RDBMS, the mapping between entities and tables is a classical question, whether you're in microservices, classical SOA, or even monolithic applications.

There is in general some mapping between entities and tables. But not necessarily one-to-one: you may require several tables for an entity, for example:

Value objects

The question about value objects is of the same kind than the question with entities: it's not realted to microservices. Value objects are objects that have no identity. So the question is whether they need to be stored in their own tables or if they are stored as a set of fields in the tables of the entity that uses these values.

Database distribution

For entities and value objects, the choice of a database per service will have a consequence on the distribution of the data: a typicial question will be:

  • should an entity be stored in one database, and the owning microservice provide everything to the other microservices that request it ?
  • or should entities (or part of the entities) be replicated in the databases of every microservice so that these stay decoupled ?
  • and what about replication when there is several instances of the same microservice (i.e. scaling).

Microservices have not much to do with DDD services

You didn't ask. But:

  • DDD services are about where to attach a functionality in the design. If the functionality cannot be encapsulated easily as an operation in a single entity it is a DDD service.
  • whatever the implementation of your DDD domain objects, you may isolate the domain from the rest of the application using a service layer, regardless if it’s a monolith or if it’s broken down into microservices
  • Microservice services are application services that are packaged in the implementation so that it can be provided via an API to other microservices or the outside world, and in a way they can be deployed independently.

I hope this helps you to see how these two set of concepts are related and avoid the initial confusion.


Should every aggregate be a single microservice and have a single DB ( since every microservice should have a single specific DB)?

Most discussions that I see align "microservice" with "bounded context".

Back at the start of the millennium, when Eric Evans was working on his book, the usual design was that you would have "all" of your domain model stored in the same logical database. Since each aggregate contains within it all of the entities (and therefore, all of the state) required to maintain its invariant, you could in theory have an architecture where each aggregate has a database of its own -- but that does complicate some of your queries. It's the sort of scaling trade off that I would defer until you really need it.

Trying to distribute the storage of an aggregate across database instances will be a bad time.

Entities = tables at the microservice DB?

Not generally - in simple cases, you can say things like "all order entites are stored in the Orders table", but it won't necessarily turn out that way (especially when you are dealing with entities that include collections AND you want to be able to implement cost effective queries of the items in those collections).

Designing your storage model is a different problem than designing your domain model; although they do include some common constraints.

What are Value objects in terms of microservices architecture?

"Values". The only reason that value objects are "objects" is that Domain Driven Design has its historical roots in the Kingdom of Nouns.

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