Think Before Coding - Comments

Uniqueness validation in CQRS Architecture - Jérémie

Jérémie — Sun, 25 Jul 2010 20:10:48 +0200

You should check the likeliness of conflicts (you can reduce them by validating uniqueness on the client/read side before sending the command) and the cost of conflicts.
If you can structuraly dismiss conflicts (like the company => boss case, or when unicity is inside an aggregate), do it !
In other cases, unicity should not affect the domain, and there's a good reason for it :
your unicity crosses aggregate boundaries. If your boudaries are well defined, a temporary breaking of unicity should be ok, since consistency cannot be garanteed accross boundaries.
If not... move your boundaries.

Uniqueness validation in CQRS Architecture - CraigCav

CraigCav — Wed, 14 Jul 2010 00:19:06 +0200

Hi Jérémie,

I've really enjoyed reading this series of posts, and this one was no exception! I particularly like the idea that there is no such thing as global scope, and the company=>boss example is perfect to demonstrate this.

This post really got me thinking.

"Instead of having a UserName property on the Employee entity, why not have a UserNames key/value collection on the Company that will give the Employee for a given user name ?"

If I've understood Udi's posts on CQRS, I think he'd probably advocate the collection of Usernames being part of the Query-side, rather than the Command side. I've heard him mention before that the query side is often used to facilitate the process of choosing a unique username - the query store checks the username as the user is filling in the "new user" form, identifying that a username already exists and suggesting alternatives.

Of course this approach isn't bullet-proof, and it will still remain the responsibility of another component to handle the enforcing of the constraint.
The choice of WHERE to put this logic is a question that is commonly debated.

Some argue that since uniqueness of usernames is required for technical reasons (identifing a specific user) rather than for business reasons this logic falls outside of the domain to handle.

Others may argue that this logic should fall in the domain - perhaps under a bounded context of managing user accounts.

In either case, since we have a technical problem (concurrecy conflicts) and we have several possible solutions, the decision of whether on not they are suitable will probably constrained by the expected frequency of the problem occuring. This sounds to me like the kind of thing that would appear in a SLA.

I guess then the solution chosen to enforcing the uniqueness constraint will depend on the agreed SLA. Perhaps it is acceptable that a command may fail hard (due to the RDBMS failing) on the few cases of concurrency conflicts - it might only be on a 0.0001% of cases.

Alternatively we may decide that it is unacceptable to allow this to occur due to the frequency of this occuring. We could choose to maintain the list of usernames in the Company aggregate, but scale out our system such that all "new user" requests in the username range A-D are handled by a specific server. If we decide to enforce this constraint outside of our domain, we can offload this work to the command handler.

What do you think?

Craig

[ping] Event Sourcing and CQRS, Events Deserialization - Scott Banwart's Blog

Scott Banwart's Blog — Fri, 04 Jun 2010 16:46:50 +0200

Distributed Weekly 48

Architecture Event Sourcing and CQRS, Events Deserialization * REST REST from scratch A RESTful Client Side Framework for Jersey WS-REST 2010 Proceedings Nestful: A Simple Ruby HTTP/REST Client Library The Open Data Protocol .NET Framework Client...

Event Sourcing and CQRS, Events Deserialization - jeremie

jeremie — Fri, 07 May 2010 11:32:01 +0200

I have one, but this is quite borring code, and I won't push the code open sourced now. Consider this as an excercise ;-)

Event Sourcing and CQRS, Events Deserialization - Dennis Doomen

Dennis Doomen — Thu, 06 May 2010 07:53:40 +0200

Excellent idea. Do you happen to have a concrete example of how you propose to do that in .NET?

Udi Dahan talks on CQRS in Paris - Olav Rask

Olav Rask — Tue, 20 Apr 2010 13:03:33 +0200

Sweet - thanks :)

Event Sourcing and CQRS, Bounded Contexts - jeremie

jeremie — Tue, 20 Apr 2010 11:34:08 +0200

@Hendry Luk> You can also split Query BCs, but based on Query requirements. A single Query BC will usually gather information from serveral Command BCs. Because presentation applications often display crossed informations from different part of your domain.

Udi Dahan talks on CQRS in Paris - jeremie

jeremie — Tue, 20 Apr 2010 11:21:07 +0200

@Olav> yes, it should.

Event Sourcing and CQRS, Bounded Contexts - Hendry Luk

Hendry Luk — Tue, 20 Apr 2010 04:54:10 +0200

"Actually the Inventory BC itself will not display lists, because the BC is part off the Command side."

Ah now I see... I thought each BC would have both command and query sub-BCs.
In many applications, a BC is a whole complete application by itself with its own UI and sometimes storage. I was thinking that inventory BC is an inventory-management application which includes its GUI client, hence the necessity of displaying the list of books, their publishers, authors, and perhaps borrowers (albeit not good example).
I didnt realise that BCs separation only happens within command-side of thing. Most of my readings have always led to understanding that each BC will wrap a command-component, and a query component.
So, for the sake of dicussion, in the case that inventory has its own separate UI application, were you saying that this will then listen to all various events (PublisherAdded, AuthorsModified, BorrowerSignedUp) and maintain its own set of "master-data", so when it receives a BookRegisteredEvent it knows how to create a flat denormalised view-model out of it?
Cheers

Udi Dahan talks on CQRS in Paris - Olav Rask

Olav Rask — Mon, 19 Apr 2010 21:32:48 +0200

Jérémie > Thanks for your reply.

I'm sorry for beeing thick. I get that data should be stored for presentation. That's what UsersWithRoleName is for. But when a "UserCreated" event arrives, i need to get the associated role name from somewhere, in order to fill in all the fields in that table.

So besides the "UsersWithRoleName" table you would have a "Role" table on the read side, to get the role names from, when new users arrive?

Udi Dahan talks on CQRS in Paris - Jérémie

Jérémie — Mon, 19 Apr 2010 19:10:38 +0200

@Olav> To show the data on the read side. So you'll have all that data in the database. This is where you'll find names and descriptions.
One difference with your domain model is that it will be stored with presentation in mind instead of transactions.
The other difference is that you can rebuild it from your event log.

Hope it helps

Udi Dahan talks on CQRS in Paris - Olav Rask

Olav Rask — Mon, 19 Apr 2010 17:36:07 +0200

Hi Guys

If anybody is stil following comments here, can someone elaborate a bit on the answers for Clément Bouillier?

Say I assign a user a role, resulting in a UserAssignedRole event containing the UserId and RoleId. When i go to update my "UsersWithRoleName" read-side table, am i suppose to have the roles stored seperately on the read side, in order to find the role name, to put in?

This could potentialy mean storing the entire model as well as the denormalized tables on the read side.. ..would you guys recommend this or do you have an alternate approache?

Kind regards
Olav

Event Sourcing and CQRS, Bounded Contexts - jeremie

jeremie — Mon, 19 Apr 2010 14:20:14 +0200

@Hendry Luk> Actually the Inventory BC itself will not display lists, because the BC is part off the Command side.
To display lists, the web application (or web service, or...) will build a persistent view model. There will be a service that will handle Domain events a populate a denormalized view of the model, probably in a SQL table. The web site will simply display this list.
This service will be in charge to listen to events from all BCs to update Persitent View Models (usually one per page).

This is important because display screen often gather information from several contexts. But the contexts themselves don't have to know this, since these aggregations are only for display (Querying/Reporting) purpose.

So, the Inventory BC doesn't know about borrowers names, the Relationship BC doesn't know about books names, but the denormalizers listen to both and can prepare the persitent view model.

Event Sourcing and CQRS, Bounded Contexts - Hendry Luk

Hendry Luk — Mon, 19 Apr 2010 09:21:03 +0200

Just to associate with your example...
Command BC issues this event: ReturnedLateToShelf { Book : bookId, By : borrowerId, After : 20 days, LateBy : 6 days }
Relationship BC catches it, and it will want to inform the user (customer-service rep) about who the borrower is. It can't just tell the user: Borrower: #1534.
It needs to tell the user the name and email address of the borrower. Full-name and email aren't part of the participating events , but they certainly are part of the Borrower entity in this BC. This BC thus has BorrowerRepository I figure, but im not sure how it's then able to retrieve the complete aggragate root of Borrower entity?
If I intepret correctly, you tend to lean toward having this BC having its own storage of all borrowers? (And publisher, authors, etc)

Event Sourcing and CQRS, Bounded Contexts - Hendry Luk

Hendry Luk — Mon, 19 Apr 2010 09:07:21 +0200

Thanks Jeremie for great explanation.
Some things are still not clear to me though.
Let's take this into your example. Your inventory reporting BC displays list of lent and returned books, along with the name of the borrowers.
If you change your implementation to be more realistic by using BorrowerID in the event (instead of fullname), then how would this inventory BC retrive the view-models of the borrower?
It can subscribe to BorrowerRegistered event and store its own data of all borrowers that it can use for reporting purpose, but it would start to get messy.
It makes sense for inventory BC to keep its own view of Books concept (query-optimised view of Book), and manage the data based on BookRegistered, BookReturned, and BookLent events. But it does not make so much sense for it to also keep track of Borrowers, and BorrorwerRegistered/BorrowerTerminate events. They're beyond the UL of inventory BC.
And we probably have many other BC that requires borrower's full-name (e.g. late-book-notifier). And we have all other concepts like Publisher, Author, Genre, Country/Town, etc that are used in almost every BC. (ie, perhaps 80% of the time, a book, in any BC, is described by its title, publisher, and author's name). Yet you only propagate all these information (events) merely by their IDs.
How do other (querying) BCs understand these IDs? They need a complete descriptive information of the entity, not just the ID. Do they make a web-service call to a central BC to get these information? Who maintains these information?
Or alternatively does each of the BCs master its own set of storage for each of these entity-types by subscribing to e.g. AuthorAdded, AuthorModified, PublisherAdded, BorrowerMovedTown, etc?
If you could explain a bit of how you would implement book-borrower scenario into your example, that would help a great deal.
Thanks again :)

Event Sourcing and CQRS, Let's use it. - Hendry Luk

Hendry Luk — Sat, 17 Apr 2010 05:57:32 +0200

Great article Jeremie.
Just 1 question, you represent borrower in events as a simple full-name string. Is there any reason or just for sake of simplicity for example?
Supposed I'm using borrowerId, how would that work in other BC, say LateBookNotifier (let's assume its a separate BC). How does this BC shows the name of the borrower? Does it communicate directly with command BC using ACL? Or does it also subscribe to BorrowerRegistered event as well (hence every BC would have duplicate data of each of the borrowers, just like they do each of the books)?
In real-world app, like the one I'm dealing with, it's rarely simply command and query BCs. I have multiple BCs, in this particular case can be: LibarianCounter BC (register,lend,return book), Inventory BC (status of each book and its borrower), and Administration (get notified of late books, impose fine). So each BC will have its own storage of all books and borrowers? When more entities come into play, wouldnt this get very messy?
Thanks

Uniqueness validation in CQRS Architecture - Clément

Clément — Mon, 08 Mar 2010 00:27:15 +0100

Hi Jeremy,

I remember talking about this with you. Crowling over the web about CQRS trying to understand more deeply the concepts, I re-read this post. I also read you discussion in DDD Yahoo group about "A possible solution for uniqueness validation in CQS". (http://tech.groups.yahoo.com/group/...)

I agree with you with most arguments, but one let me sceptical: it is about how do you implement "...keep the directory on disk..." (just before your conclusion) or "...May be one of these new key-value stores could help with that...." (as bodrin writes in DDD list) ? Particularly when using Event Sourcing ? Is it several indexes managed by your AR repository ? Does it mean that it is CommandHandler that calls your Repository, or does your Company has access to the Repository or somewhat else... ? Could you be more precise on this point please ?

Note : I see a solution around Udi comment on the DDD list: rely on the constraint violation management of the store (event or state in fact). It seems really simple using a RDBMS system but I am wondering if you were using something that fakes the same constraint violation management in a custom event store...

Clément

Event Sourcing and CQRS, Snapshots ! - Jérémie

Jérémie — Wed, 03 Mar 2010 14:40:08 +0100

@Leonardo> State used for deciding state changes is usually not that big, I think at least what is most needed to run your domain logic can fit in memory, even on large applications. The rest will stay in the event store (because it was published once), and in the query context in denormalized views, but your aggregate root won't need it for transactionality.

Event Sourcing and CQRS, Snapshots ! - Leonardo

Leonardo — Sat, 27 Feb 2010 17:27:48 +0100

Thanks for the answer in an entire post, Jérémie.
Having snapshots is a good idea to solve that problem.
Now, what I don't fully understand is what you say about having the model entirely in memory. I'm being reluctant to believe that an entire model can fit in memory, taking into account that CQRS is meant for scalable applications with very big, perhaps cross countries applications, with tons and tons of data. I'll try to have an open mind if you try to convince me the other way.

Event Sourcing and CQRS, Let's use it. - Jérémie

Jérémie — Thu, 25 Feb 2010 10:46:03 +0100

@leonardo> I made a new post to answer the question : http://thinkbeforecoding.com/post/2...