Domain Driven Design, How do I deal with user specific data?

Question

After reading Eric Evans' DDD, I'm trying to apply it to the project I'm managing. There are some user specific query data and I'm not really sure of how to implement this in a DDD way.

For example, if a user queries notices, the application should tell the user wether each post is read or not. Normally in such situations, I would respond with data that looks like following:

{
    "notices": [
        {"content": "foo", "is_read": true}, 
        {"content": "bar", "is_read": false}
    ]
}

Suppose there is Notice entity and Read entity that saves wether a User has read it. Also assume that there are so many users reading the notice that retrieving all users for the is_read is not a efficient way.

• Since Read entity is never queried without Notice entity, I could put it inside a Notice aggregate. Then implement query function taking the requesting user as parameter.

• Or I could separate NoticeRepository and ReadRepository, query notices and then join them in the application layer with reads queried with notice ids.

The first option seems that it is assuming an user querying the notices and corrupting the domain layer with application logics. On the other hand, the second option gives me a feeling that I'm implementing a simple feature in an unnecessarily complicated way. And I cannot really think of other options right now.. What could be the best practice for such a case?

Answer 1

I wouldn't have a Read entity. Just Notice and User. In User you would have a list of Notice ids that the user has read (or viceversa, in Notice you would have a list of the User ids who have read the Notice).

Then , to query the info you need to show in the user interface, you have several alternatives, as Vaughn Vernon says in his book Implementing DDD (page 512):

• DTOs

• Mediator

• Domain Payload Object

• State Representations

• Use Case optimal repository queries (closed to CQRS)

• Data Transformers

Answer 2

This need to go all in a Query Service,

The book of Eric Evans is good basis and it has evolved to more modern patterns now, for instance CQRS in the book of Vaughn Vernon, Implementing Domain Driven Design (IDDD).

Your query service would be responsible of displaying a list of notices, updating a read column for this user in a separate table.

You might have a look at some example of query services (written in java) here:

https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_collaboration/src/main/java/com/saasovation/collaboration/application/forum/ForumQueryService.java

https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_collaboration/src/main/java/com/saasovation/collaboration/application/forum/DiscussionQueryService.java

Answer 3

I cannot really think of other options right now

I can see two possible issues that could be tripping you up.

First, your domain model may be missing an important concept. How do we know if a Bob read a particular notification or not? There may be some entity in the domain, perhaps an Acknowledgement, that captures Bob, and the document that he read, and perhaps other information interesting to this domain (which version of the document did he read? When? What channel? when? and so on).

Thus, the view that would produce would look something like the list of active notifications left joined to the acknowledgements from Bob.

The other thing that could cross you up is that trying to do joins "by hand", using repositories to fetch data, is a real drag. Furthermore, what people have come to realize in the years since the blue book was written, it may not be necessary. Because queries are safe, they don't change the underlying data -- and if the underlying data isn't going to change, we don't really need a domain model to protect a business invariant.