Posts tagged DDDSample

Command Query Separation is an architectural style which encourages building two separate models for one particular domain. One model is optimized for commands (modifications, like inserts, updates and deletes) and the other is optimized for queries (probably using star, warehouse-like schema).

The goals of CQS are to make both subsystems scale well using methods best suited for each one and to free the command model (which encapsulates the core business logic) from UI related code.

DDDSample is an implementation of sample from Eric Evans’ book and, as such, is not using CQS principles. It is that because its purpose is to demonstrate basics of DDD not ‘polluted’ by derived concepts.

Yet the DDD ‘knowledge crunching‘ process demonstrated in the book by Evans leads to a model which is very well suited for scaling. How is it done?

It is simply because DDDSample (as well as my .NET version) is built according to other good DDD practice–one which says that communication between aggregates is asynchronous. Despite not being named officially as CSQ-driven, DDDSample model has two aggregates representing the same concept (Cargo), one optimized for commands and the other one for queries.

Most of processing-intensive operations of Cargo entity are being done via Handling aggregate which asynchronously pushes notifications into the Cargo aggregate. The latter contains a lot of redundant information which is optimized for searching cargoes and displaying cargo information on the screen.

When I was thinking about future of DDDSample.Net I thought about CQS in the first place. After careful analysis I know it will not give any breakthrough in the field of scalability, but I hope it will make these scalability enabling aspects more explicit in the codebase and will clean up the core business code from presentation concerns.

Entities are the stars of the domain model. They are the most valuable elements in terms of amount of business logic. They usually represent the most important real life concepts – those which have its own identity. And identity is something which is critical to the entities.

Entities which have different IDs are different entities. That is what the books would told you. But how does it look like in practice?

In DDDSample there is special interface for entities: IEntity. It defines one method
boolean sameIdentityAs(T other)
Implementation checks whether the other object is null (in this case returns false) and, if not, compares business identities of the objects.

There is also the equals method overridden on all entity classes. equals compares all the data contained in particular entity.

I think I understand some of the reasoning behind this solution. The sameIdentityAs method makes explicit that we are comparing business, not database, keys and that we care about identity. What I don’t understand is the equals method. Why on Earth should I compare entities by their value? Ideally (in CQS?) they should expose no values at all.

I decided to get rid of the equals (in my, C#, case Equals) overriding. That was the easy decision. Now the hard one: what to do with the SameIdentityAs? As you could read in the previous episode, I decided to get rid of similar method on value types. I think I had strong reasons there, but here?

The reason I consider giving up on the sameIdentityAs at all are ORMs. They provide me with an Identity Map out of the box – a warranty that two object references with same DB key are in fact one object instance on the heap. With that promise I can simply use == and != to compare addresses and the result is the same as business key comparison.

I strongly believe that all of my applications would use ORMs to store data in the foreseeable future. Even if I am wrong, in case I had to change my data access strategy completly, I wouldn’t expect that the change would be simply switching the DLLs. It certainly would be a painful task. I won’t make it easier just by pretending that I am not dependant on an ORM. Yes, I am and this fact is reflected clearly by the structure of the model. If I would plan to use OODBMS, I would structure my model completely different.

So, to sum up, we will get rid of those sameIdentityAs methods as well and use plain C# equality operators for both entities and value objects. In case of entities we will depend on Identity Map implemented in the ORM. It will make our code more consistent in context of object comparison.