How to model an entity's current status in DDD

Question

I am trying to get to grips with the ideas behind DDD and apply them to a pet project we have, and I am having some questions that I hope that someone here would be able to answer.

The project is a document management system. The particular problem we have regards two notions that our system handles: That of a Document and that of a DocumentStatus.

A Document has a number of properties (such as title, author, etc). Users can change any of the Document's properties through out its life time.

A Document may be, at any time, be at a particular state such as NEW, UNDER_REVISION, REVISED, APPROVED etc. For each state we need to know who made that change to that state.

We need to be able to query the system based on a document status. An example query would be "Get me all documents that are in the REVISED state".

"Get me all documents whose status has been changed by user X"

The only time that a Document and a DocumentStatus need to be changed in the same transaction is when the Document is created (create the document and at the same time assign it a status of NEW).

For all other times, the UI allows the update of either but not both (i.e. you may change a document's property such as the author, but not its state.) Or you can update its state (from NEW to UNDER_REVISION) but not its properties.

I think we are safe to consider that a Document is an Entity and an Aggregate Root.

We are buffled about what DocumentStatus is. One option is to make it a Value Object part of the Document's aggregate.

The other option is to make it an Entity and be the root of its own aggregate.

We would also liked to mention that we considered CQRS as described in various DDD documents, but we think it is too much of a hassle, especially given the fact that we need to perform queries on the DocumentStatus.

Any pointers or ideas would be welcomed.

Answer 1

Domain

You say you need to be able to see past status changes, so the status history becomes a domain concept. A simple solution would then be the following:

• Define a StatusHistory within the Document entity.
• The StatusHistory is a list of StatusUpdate value objects.
• The first element in the StatusHistory always reflects the current state - make sure you add the initial state as StatusUpdate value object when creating Document entities.

Depending on how much additional logic you need for the status history, consider creating a dedicated value object (or even entity) for the history itself.

Persistence

You don't really say how your persistence layer looks like, but I think creating queries against the first element of the StatusHistory list should be possible with every persistence mechanism. With a map-reduce data store, for example, create a view that is indexed by Document.StatusHistory[0] and use that view to realize the queries you need.