Domain Driven Design and aggregates

Question

In our system we have a database where many tables have with a lot of columns, in some case more that 300 columns. Lets use an example - a car. We have a car table which contains 300 columns. Besides the id of the car, the rest of the columns contain data related to the car fx. the dimensions of right seat.

The question is how to we map this table into a DDD aggregate without loading all columns?

DDD says the repository loads the entire aggregate, but in most cases the customer only wants to see a small part of the aggregate. The car aggregate will also have a lot of methods calculating a variety of things and some cases the data needs to be loaded from other tables.

How do we implement this the DDD way? Domain services?

Are we barking up the wrong tree? Should we be using CQRS instead?

Please disregard the fact; the database is a mess.

Answer 1

It seems that your problem is that you map the aggregate and the view the user wants to see 1:1. Solely because we talk about an aggregate it's not 1:1 the view. (you said it by your own "but in most cases the customer only wants to see a small part of the aggregate").

A benefit of using CQRS (or "only" CQS) is that you can concentrate on the domain, means you can model you commands and views (e.q. query) from the user/customer perspective, disregarding you current database design.

Take a look at effective aggregate Design by Vaughn Vernon, possible it helps.

Answer 2

In simple oop, if you find some behaviour need only a subset of the fields, you may extract them to another Class and delegate the implementation to it.

In your car case, you could do the same refactoring. Then you could use lazy-loading: Load car first and load other local entity of car when needed. I think this is more an infrastructure issue than domain driven design.

And of course, if you find the persistence infrastructure hampers you from modeling. You could use sperate persistence objects. But this requires more resources at the beginning.

On the other hand, if you have a legacy database, I think it's harder to adopt CQRS. This may bring your team too much burden.

Answer 3

CQRS and DDD are not mutually exclusive. The domain should focus on actions/calculations/"real" work. You probably want to use a read/query layer to get to that subset of data the user would like to see.

Try not to query your domain. If you find yourself asking the questions you are asking now it usually means you are, or are considering, querying the domain. That just leads to pain.

So DDD and CQRS can work well together. There are also various levels of CQRS so you will need to get the balance right :)