CODEWITHSUNDEEP
javajakarta-eedomain-driven-design
LuckyLuke
LuckyLuke

Reputation: 49077

How to decide whether one object should be part of an aggregate or not

After I started reading about DDD and aggregates I seem to try to fit everything into aggregates. It doesn't help any particular that almost every blog post or tutorial etc uses the same example: Order and orderlines.

What does it mean that an object can live on its own or not? Does it mean that it can't live on its own in my modelling of the domain, or does it mean that it doesn't live on its own in the real world?

I am making an application where a user can track their driving. Like, duration, distance and so on.

I have made a StudentDriver class for the purpose of modeling the person, a DrivingLog for modeling the "book", and DrivingRecords for modeling each "line"/record that the user make when he/she has driven. This contains the duration, distance and so on.

So now the question is: Should the StudentDriver be seen as the aggregate root of all these classes and every action go through the StudentDriver? Or should StudentDriver be a root and the DrivingLog be the other root and then the StudentDriver and the DrivingLog would have a association between each other?

It would be nice to hear how you decide this? Both in this example and also in general.

Upvotes: 2

Views: 179

Answers (2)

Alex D
Alex D

Reputation: 30445

DDD was a great book, and I also enjoyed reading what Evans said about the Aggregate pattern. I think you may be taking things a bit too far, though.

As I understand it, the purpose of the Aggregate pattern is:

When every part of a program interacts with every other part, it becomes difficult to understand (and debug), because you can't understand any one part in isolation; to understand any one part, you have to understand everything.

Additionally, when interactions go in every direction, bugs which corrupt object state are hard to track down, because you have to look everywhere. If the code which can modify a certain object is limited, it's much easier to guarantee that it always leaves that object in a correct state.

With the Aggregate pattern, you have one object which is the Aggregate "root", and other objects which are "contained" by the root. Only the root can "touch" the contained objects, which cuts down the number of pathways which interactions can go through.

This is a useful idea to have in your conceptual "toolkit", but you don't need to use it just for the sake of doing so. Rather than worrying about what it means if "an object can live on its own", look at what you actually want to do with StudentDrivers and DrivingLogs, and think:

Will this code be simpler and more manageable if I allow other classes to directly work with DrivingLogs, or if I require them to call methods on StudentDriver to retrieve or modify that data? Imagine how the code will read either way. In one case, you might be writing drivingLog.mileage() from "outside" classes; in the other, you would be writing studentDriver.loggedMileage().

One of the best points made by DDD was the importance of matching model and implementation, which even includes things like choosing identifiers (in your code) which make sense in real terms. In harmony with that, you can also look at the operations which your code is performing, and think: if I think about what this operation represents in real terms, is it something which is done to drivers, or to log books? If in reality the operation is something which is done to log books, then don't make it use StudentDriver methods which delegate to DrivingLog, just because you want to use the Aggregate pattern.

Upvotes: 5

reederz
reederz

Reputation: 971

Aggregation is relationship between two classes which have whole/part relationship. E.g. Car is whole and a wheel is it's part.

In your case you could make StudentDriver an owner of DrivingLog, if it belongs to him. If there wasn't an existing student, it would not make sence to keep a DrivingLog. Thus DrivingLog cannot exist on it's own.

StudentDriver should be a root and be aware of a DrivingLog. But DrivingLog is not supposed to be aware of StudentDriver.(just like unidirectional assosiation)

Upvotes: 0

Related Questions