I am trying to implement DDD into my ASP.NET Core app using Ardalis' clean architecture template which has some helpers for Aggregates and Repositories. One of the things it does is force you to only use repositories for aggregate roots, which is the recommended way to do it in DDD if I understand it correctly. However, I face the following issue:
I have the Document
entity (the aggregate root) which has a DocumentType
. They are stored in DocumentAggregate
. However, looking from the frontend project, I need a way to list the available DocumentType
s to the user. I could create a DocumentTypeAggregate
but this would result in an anemic aggregate (and it would over-encapsulate since there is no context where DocumentType
can be used unrelated to documents).
How could I model this scenario in order to fit the DDD pattern?
You could access the data through a static
Document.Enum.GetTypes()
, because read-only methods on non-aggregate-roots are fine: no invariants are endangered. There are also competing philosophies toRepository<T> where T : IAggregateRoot
that are fine with querying non-root entities, as long as all commands (writes) still go through the root entity. Read more here: https://stackoverflow.com/a/53433681/4362799. Thus you could run queries with specifications on any domain type you'd like, as long as you don't mutate. You could even guarantee this through read-onlyDbContext
instance injections for queries.An enum type couldn't be an aggregate root, because aggregates must be an entity type and enums aren't. You can model your enums as value objects through enumeration classes if you'd like, but it is fine to use vanilla enums as well.