CODEWITHSUNDEEP
domain-driven-design
oakman
oakman

Reputation: 297

Correct design of aggregate roots

Somewhere far, far away in a domain galaxy there is mention of

Given my current model where 'Places' are the aggregate root that holds 'Measurement values' I have a dilemma:

Users wishes to view one type of measurement values at a time and there are quite a lot of measurement values. To load all measurement values when only some of them are needed seems unneccessary..

Eg. Im stuck on how to organize/model the need "Show me waterflows (measurement values) in River X (Place) between time A and B"

Is it allowed to instantiate River X aggregate root only partially loaded with the type of measurement values concerned in a given use case? Are there other ways of modelling measurement values and their origin?

Please let med know your thoughts...

Upvotes: 0

Views: 67

Answers (3)

Arvin Yorro
Arvin Yorro

Reputation: 12107

I fail to see the real problem. You said that each Measurement is tied to a specific Place, then you don't have to load all Measurements.

Using correct data layer configuration, you can load the required Measurement by selecting/loading/instantiating only it's parent (Place).

Upvotes: 0

BAD_SEED
BAD_SEED

Reputation: 5056

I think that your aggregate is consistent as it is. Your dilemma as nothing to do with domain model but rather than with a presentation model.

I will consider the possibility to deserialize each measurement in a NoSQL instance, in this way your presenteation layer could filter and make any query without affecting the consistency of domain layer.

Upvotes: 1

Codescribler
Codescribler

Reputation: 2305

Correct me if I'm wrong but it sounds very much like the data model and storage are impacting the design of your system? If this is so it may be the cause of your dilemma. A key part of the benefit modeling using aggregates is it is free of dependencies. Dependencies such as databases and data models. There is no direct 'view' of an aggregate, so it's not shaped by the view. This makes aggregates much easier to design. They are much more focused on solving the problem. And are therefore great candidates for doing complex stuff.

If it turns out you don't need aggregates to model your domain. You can then just focus on an efficient storage and retrieval mechanism.

In other words...

Don't tie yourself up in knots doing DDD if you don't need to.

If it helps I created an infographic on common DDD mistakes. You may find it helpful. You can find it here.

By the way, I think DDD is a great way to go, but only if your domain warrants it. Appologies if I have misunderstood you.

Upvotes: 0

Related Questions