I have been building a new application using my current understanding of domain driven design. So far I have a bunch of classes representing entities in my domain and a repository to retrieve from/persist to the database.
The problem I am running into is that in the UI I have a need to display a few lists where the items in the list don’t map directly to any entities in my domain. Some of the list could be built by doing a fairly deep eager load of certain entities, but other data is essentially synthesized at retrieval time and is not part of any entity. Let me provide an example that will hopefully explain the problem more clearly.
In my domain I have evaluations (a set of questions to answer) and responses (the answers that each user has provided to the evaluation) to those evaluations. I also have actions. Each action represents an action that has been taken with a response (submit, approve, reject, etc.). I also have users.
One of the lists of data that I need to display would include responses and evaluations (that have not been responded to), then each line would include information about the user who is currently working with the response (this is determined at retrieval time by looking at the actions that have been taken on a response). Each line item would also include zero or more child items which are actions that have been taken on the response so far.
The problem is that as of right now I don’t have any way to represent this entire data set with my domain entities. My first reaction would be to just retrieve a datatable from the database and bypass my domain entities. But I see a lot of value in working with domain objects and having the relationships between different entities baked into the objects themselves. So my next idea would be to modify my domain entities to support these lists, but I am concerned both that I would be adding strange properties to my entities just to support these listing scenarios and that I might be hurting performance by essentially doing deep loads of objects when I only need that data in a few places in my apps.
I’d suggest not viewing this as something you have to shoehorn into your entities, but rather provide a service (in the domain-driven design parlance) whose job it is to collect this data when requested and present it as a view. This frees you up from having to rework your entities in an clunky way.
The awkward design friction you’re feeling here is a good thing. It’s a clue that things aren’t quite fitting together.