CODEWITHSUNDEEP
javaspringjdbcdomain-driven-designentity
Alex Vergara
Alex Vergara

Reputation: 2209

Domain vs DTO on database entity relations

I have three tables on a database, and one old and good query that joins the interesting columns for the usecase on a DTO object after use a RowMapper. Classical Java approach.

But I am wondering, how can I convert this into a DDD implementation? How can I use entities for solve the problem without having 3 separated queries to create the models with it's fields, and then create a DTO just for create the object with the desired columns?

What I am missing? Or should be better the already implemented way?

Upvotes: 3

Views: 1238

Answers (1)

ArwynFr
ArwynFr

Reputation: 1712

You cannot convert that model to DDD.

DDD is about creating a business model in a separate layer: the domain layer. The purpose of this layer is to verify that any state-changing operations does not violate your business rules. How you model your domain entities must be driven by the use case you are handling, not how the data is stored: the domain layer is said to be persistence agnostic. It doesn't matter whether the data is stored in one or multiple stores, RDBMS, nosql, files, etc ... that's ther purpose of the infrastructure layer.

Domain object are read by a class called a repository. The repository behaves like an in memory collection of domain object, but actually re-hydrates objects from the persistence store(s). It operates as a mediator between your persistence model and your domain model. Since models may differ, the repository can flatten relations, join data from different sources, and ignore some columns if needed.

When querying your state, you don't need to use the domain layer at all. The purpose of that layer is to validate state-changing operation, business-wise, but this is unnecessary when querying the state. In that situation, you can implement classes, called mediators, that will query your database and produce presentation layer DTO. Like the repositories, mediators are adapters between your persistence model and your presentation model. It can join data from multiple persistence stores, flatten relations, and ignore columns as well.

Whether to use an ORM, or not, for accessing the database, is an implementation detail of your infrastructure layer. It has nothing to do with domain modeling, which is about your use cases and business rules validation.

Upvotes: 3

Related Questions