Is correct to have an aggregate with fields different than database object?

user_14138763 0
Viewed 92

I'm trying to apply DDD and I have some doubts. I'm reading Scott Millet DDD book and I've just read Aggregates chapters.

Imagine a simple domain model like this:

class Candidate
val id: CandidateId
val name:Name
val musicStylesPreferences: List<MusicStyle>
val sportPreferences: List<Sport>
val smoking: Boolean

enum MusicStylePreference
ROCK, METAL, POP, HIPHOP

The other objects are like this.

If we think about persisting the Candidate, my approach is like this:

*DatabaseObject*
CandidateVO
val id: String
val name: String


MusicStylePreferenceVO
val candidateId: String
val StyleName: String

When I persist the Candidate object in database I will persist in the appropriate table and when I hydrate the aggregate, I will query the tables.

I'm not sure if this approach is correct, I'm also thinking that maybe the objects like MusicStylePreference, Smoking etc ... doesn't need to be consistent and transactional (some of the advantages of aggregates) and can be outside of the aggregate Candidate.

What do you think?

I appreciate any answer. Thanks :)

aggregates modeling domain-driven-design oop java
1 Answers

It's correct and even necessary. The Aggregate should model the ubiquitous language while the database field names are about persistence and have other separate goals and requirements.

A contrived example; The database might save a fullname as "Firstname", "LastName" but the aggregate just has a string.FullName that's a concatenation of the values. It doesn't care how they are persisted or even where.

user_24972880
Related