Comments on: CQRS à la Greg Young

By: Mark Nijhof

Mark Nijhof — Tue, 09 Feb 2010 17:26:22 +0000

@Ertugrul
You are correct the Event Store is INSERT and READ only, no events will ever be changed or deleted. But an Aggregate Root would not get a repository to retrieve another Aggregate Root from the Event Store. But an Aggregate can contain other Entities if that is needed for domain behavior, but these are then ‘managed’ by the Aggregate Root and retrieved by retrieving the Aggregate Root. If you need state from other Aggregate Roots then you would use a service that uses the reporting repository to query the reporting side for this state, this is because the domain repository can only retrieve by Id, so no querying.

Hope that helps.

By: Ertugrul

Ertugrul — Tue, 09 Feb 2010 14:38:44 +0000

Hi, it looks like there is an arrow from the “Event Store” back to the “Repository” and another one labeled “Aggregate” from “Repository” to the “Domain Model”. Then the Event Store is INSERT and READ only but not “write only”?
Does this mean that we are actually retrieving other Aggregates from the repository by not “querying” but by recreating them from the event store via the Repository, whenever we need them during Domain Logic?

By: Mark Nijhof

Mark Nijhof — Sun, 07 Feb 2010 18:31:44 +0000

@marko
Sorry for the late reply, your post got somewhat forgotten

In this case you could choose to implement a view model that assumes certain behavior from the domain. So it will do some basic checks to verify that the command is ok, then after sending the command and receiving a OK back (command either receive an Ok or Exception back) it assumes that the order is added and it will add it to its local representation of the list with orders (if it matches the filter criteria).

But to be honest there are other options as well all depending on how critical it is that you need the last data in each client vs only the client that submitted it. Anyway surely a whole new post

Hope this helps.

By: DDDSample 0.6 « Simon says… architecture!

DDDSample 0.6 « Simon says… architecture! — Fri, 29 Jan 2010 06:32:11 +0000

[...] implementation. The most import ones come from Udi Dahan and Greg Young (which is best described by Mark Nijhof). My own implementation is somewhat close to Udi’s ideas (at least I hope so;-). What I [...]

By: Mark Nijhof

Mark Nijhof — Thu, 28 Jan 2010 18:11:10 +0000

@John Davidson Sure I can and I believe my reply was arguing his point of view in the exact same manner as he was making his point. Btw you know your IP is being recorded Mr_Simple?

By: John Davidson

John Davidson — Thu, 28 Jan 2010 18:00:04 +0000

Apparently you can’t take rational, justified, discussion that may not agree with your position. Mr_Simple was simply stating good luck finding a client that will pay you to program this heavyweight solution.

By: marko

marko — Wed, 27 Jan 2010 22:33:53 +0000

>> But when you system starts to grow you might get some performance problems and then you could start by implementing a bus disconnecting the publishing of the events and handling of these events. This means that it is possible and likely that your event store and reporting database are not completely in sync with each other, they are eventual consistent. Which means that it is possible that the user sees old data on his screens.

>> Depending on how critical this really is you can have different counter measures for this, which I will be going into in a different post as this is also not something the example provides.

Mark, I apologize if you have already discussed this as part of a newer post, but wonder how you handle the eventual consistency issue for cases where it’s difficult to be tolerant of any delay?

I’m particularly thinking of this use-case….

User is displaying a list of objects (eg. Orders), that are filtered in non-trivial way (eg. all Orders in a certain status, over a particular date range, etc…). The list would be rendered using the reporting db.

Now the user creates a new Order or Modifies an existing one from the list, then saves it to the domain model. If it update is successful, the screen is to render the list of filtered Orders, which should include the new/modified Order if it matches the filter.

It seems like the UI will have to immediately see the domain model change in the UI database?

What would be appropriate way to handle this situation?

Thanks Mark.

Marko.
.

By: Mark Nijhof

Mark Nijhof — Wed, 27 Jan 2010 09:54:40 +0000

@Mr_Simple
Apparently you didn’t understand everything perfectly, because if you did you would have seen that this really isn’t gold plated programming, but that there are actual business reasons behind the whole architecture pattern. So yes when you have business needs that this pattern solves for you then there are clients that pay for it. Something that isn’t really difficult to understand all together. And hey the code works without the unit tests, so if you feel you don’t have to write them, then please don’t.

It is too bad you left a fake name and e-mail address else we could see if we had such a client for you indeed, all-do with this attitude I doubt they would trust you to do a good job.

By: Mr_Simple

Mr_Simple — Wed, 27 Jan 2010 03:19:26 +0000

I understand everything perfectly, but do you actually have clients that will pay you (or give you the time) to write the zillion lines of code (and unit tests, and documentation) and explain to the junior programmers you will be handing off to how all this stuff works?

Man we’re talking about turning 40 hours of normal high quality work into 60 hours of gold plated programming. Yahoo! Gimme that client!

By: Mark Nijhof

Mark Nijhof — Sun, 24 Jan 2010 18:31:56 +0000

@Erik I am not sure what you mean by parameters? You mean the data in the events? Well those can be (and I would do that next time) be value objects. But I don't see then being domain objects as in Entities and such as that would default the purpose of having a write only domain. An event is only a POCO so no behavior. @Nigel King Well with Event Sourcing each event will be persisted, but they are not serialized to fields in a DB, instead the whole event is serialized into a single column in the DB. Each different event type shares the same table and column for this. Indeed AR Id and Event Version are what makes it unique, but when using GUID as AR Id then you don't need the version. However I guess it would help speed up the event retrieval. Hope this helps.