DDD Read Models: Why Reads Do Not Always Need the Domain Model

When I started working more seriously with DDD, I had a simple concern: if a domain model exists, perhaps every read should go through it.

Otherwise it can feel like we are "bypassing DDD."

In practice, that quickly became inconvenient. An admin table might need a few fields, filters, sorting, counts, and data from several tables, while the domain model exists for a different purpose: protecting rules when state changes.

After the article about aggregates and consistency boundaries this distinction became especially clear to me: an aggregate defines a consistency boundary, but that does not mean every SELECT must reconstruct the whole aggregate.

This does not mean reads and writes need to become two separate applications.

It is enough to acknowledge that they are optimized for different questions.

For state changes I want a strong domain model. For a table I want a simple and precise query that returns exactly the data the interface needs.

The code looks "properly domain-oriented," but problems appear quickly.

Rendering a list starts requiring a lot of state that no invariant needs. Extra relations, counts, N+1 queries, or complicated eager loading appear.

It gets worse when entity methods are added only because one UI table wants one more column.

This object does not need to know whether Product can be activated, which state transitions are allowed, or which invariants must be protected.

Its responsibility is much simpler: carry the data required by a particular read.

This is what I mean by a Read Model.

This query does not reconstruct the domain aggregate and does not try to.

It simply reads a projection of the data.

If the table needs a status filter, name sorting, and registration counts, the query can be written specifically for those needs.

This was an important realization for me.

DDD does not require every SELECT to pass through an entity. It helps model the domain and protect important rules.

In the first DDD article about the point where CRUD stops being enough I started from exactly this idea: DDD becomes useful where the system must protect behavior rather than merely store data.

A Read Model does not bypass those rules when it only reads data and is not used as a shortcut for changing domain state.

If a DTO or query result starts getting an activate() method, the two models are being mixed.

Commands that change state should return to the domain path and the aggregate rules.

This is the important boundary for me: reads may use an optimized projection, while writes go through the model that protects invariants.

The client does not need to know the internal aggregate structure.

In fact, if an API mirrors the domain model one-to-one, the external contract becomes coupled to internal modeling decisions.

A separate read model allows the client to receive a stable and convenient data shape.

This is another thing that used to look like duplication to me.

Product in a list, Product on a dashboard, and Product in an export answer different questions.

We do not need one universal object with every possible field merely to avoid several small read models.

This class is not a domain service.

It does not make domain decisions. It simply answers a read question.

This distinction is useful to me: a command/application service coordinates state changes, while a query service returns data for reads.

In the article about Application Service and Domain Service I wrote that an Application Service coordinates a state-changing use case: transaction, repository, external dependencies, and domain behavior.

A Query Service has a much simpler goal: retrieve the required data projection.

It does not need a state-changing transaction if it only reads.

I do not introduce a Read Model only for performance, but performance often becomes a useful side effect.

A list query can select only required columns, calculate aggregates in SQL, apply pagination directly, and avoid loading a full behavioral model.

This is especially visible in admin tables and analytical lists where the read shape is richer than one entity.

In AVN Center, this topic appeared naturally when state-changing rules were joined by lists, status views, and data shaped for different screens.

I did not want the domain model to know how an admin table was rendered.

I also did not want a table layout to dictate the shape of the domain model.

This continues the idea from the article about domain boundaries in a growing system: boundaries become clearer when we look at responsibility rather than simple data proximity.

This also helped me avoid unnecessary complexity.

You can have a dedicated query object and DTO for reads while still using the same database and the same application.

You do not need a separate store, asynchronous projections, or complex infrastructure immediately.

I add that complexity only when there is a real reason for it.

I look for several signals:

• The screen needs only part of the aggregate.
• The list needs data from several tables.
• Counts, sorting, or filters are required but are not domain behavior.
• The API has its own stable response shape.
• Loading the domain model creates unnecessary relations or N+1 queries.
• Domain entities start gaining methods only for one particular screen.
• The operation is read-only and does not need to protect an invariant.

My main mistake was assuming that a strong domain model must also be the only data shape used across the entire system.

Its real value is different: it protects rules and valid state changes.

A Read Model has another job. It gives a specific screen, table, export, or API exactly the data required for reading.

I am not bypassing DDD when I read directly. I bypass the domain only when I try to change its state without going through its rules.