Tag Info

Hot answers tagged

10

There are always trade offs to consider between conflicting design principles. The way to resolve it is to look at the underlying reasons behind the principles. In this case, being unable to run a query without running the command is problematic, but being unable to run a command without running the query is generally harmless. As long as there's a way to ...


9

Disclaimler: I'm only taking my first steps in the CQRS world, but I can offer my current understanding of the matter and we'll see if others confirm. All I write below has an underlying "as I see it" theme, and is not authoritative. The 80% case To answer your question, commands are indeed a point-to-point affair. When a command enters a controller (MVC ...


8

Decoupling only works if there really is separation. Consider if you have an ordering system: Table: CUSTOMER Table: ORDER If that's all you've got, there's no reason to decouple them. On the other hand, if you have this: Table: CUSTOMER Table: ORDER Table: CUSTOMER_NEWSLETTER Then you could argue that ORDER and CUSTOMER_NEWSLETTER are part of two ...


6

You've run into a problem that many have before you...a database optimized for reading is seldom good for write efficiency and vice versa. One approach that has evolved from this read-write impediment is CQRS (Command Query Responsibility Segregation). Despite Wikipedia linking the two together CQRS and CQS are technically different. CQS just demands that a ...


6

(Disclaimer: I am the author of Scritchy) I can not talk for the other frameworks, but in my case, Scritchy merely exists because I wanted to provide a quick and easy to use tool for writing CQRS apps, also taking away some of the burden of writing similar command handlers over and over... As the experts are saying: CQRS in it's most basic representation ...


5

Where I work we have an ESB to which 6 different applications (or should I say "endpoints") are connected. Those 6 applications work with 3 different Oracle schemas on 2 database instances. Some of these applications coexist in the same schema not because they are related but because our database infrastructure is managed by an external provider and ...


5

REST works OK with a command model... the commands basically become nouns, or worker resources. So instead of using /blah/blah/SearchByName You'd have a "search" (noun) resource /blah/blah/search?Name= I've always felt that's kind of a word game, but it does has the benefit of keeping your semantics resource oriented. In the case where the ...


4

Decoupling databases and keeping the data consistent between them is an expert level task. It is very easy to get wrong and end up with the problems of duplicates etc, that the current system is designed to avoid. Frankly, taking a working system and doing this is pretty much a guarantee of introducing new bugs for no real value to the users.


4

There are several ways of going about this. You know your team best. It's best to ask yourself at what level of abstraction you need to speak for them to comprehend. Cqrs is really about seperating read logic from write logic. This is best explained by comparing it to todays layered architecture as promoted by database vendors (video section over on ...


4

You shouldn't delete the events from your event store. These represent something that happened. If something happens now, then you should know it too, therefore add an event that will force your aggregate to go back to some previous state. That's a pity to delete information from your database. think about the example of the cart from greg young and the ...


4

To try and answer your question, lets look at where the pattern came from. Command Query Separation (CQS) where the querying will not change the state of the object (Only the commands would). The key point (in this context) is a class would consist of both Commands and Queries. Command Query Responsibility Segregation (CQRS), holds the same principal ...


4

I haven't heard of Command-Query-Separation(CQS) before, but it seems that it would relate to Single Responsibility Principle(SRP), which states that a function/class ideally should be responsible for doing one thing and one thing only. If your command code is 20 lines of code and query code is another 30 lines and they are all in one function body, clearly ...


3

Not sure that there is a 'one true way' answer for a design approach that, to be fair, is still evolving. First, DDD and CQRS are not the same thing although the CQRS folks seem to have derived from a DDD-influenced starting point. There's a lot going on in the DDD mindset and much of it has to do with properly defined boundaries of problems, communication ...


3

With multithreading, you just can't separate queries and commands, unless you have an external lock which serializes calls. The usual approach looks like this: // query + command // moves value at top into external thread-local storage `value` // may fail and return `false` bool ThreadSafeStack::try_pop(Value& value) { lock_guard guard(m_lock); ...


3

I'd do the simplest possible thing that would work, which (for me) would be to keep everything in a database. I'd probably store the media outside the database, just to reduce the load on the connection pool (transferring several GB of data can tie up a DB connection for a long time), but other than that just keep it simple. Write every configuration ...


3

I've seen the worst possible nightmares in software architecture due to data integration, and the best weapon against this type of mess that I've encountered so far id DDD-Style Bounded Contexts. Which is not very far away from "SOA done right", on a certain sense. However, data itself is not the best way to attack the problem. One should focus on the ...


3

I think you need to separate two types of validation in this case; domain validation and application validation. Application validation is what you have when you verify that the command property 'text' is between 20 and 200 characters; so you validate this with the GUI and with a view-model-validator that also executes at the server after a POST. The same ...


3

I think you are on to a winner here. You have several options for scaling (from easiest to requires some effort). Buy a bigger machine. Run each component on its own server. Run more servers for each component (except for the Database) Replicate the database and service the "visitors" queries from the replication. Partition the database by "member id" and ...


3

Funny, this question just reminded me of exactly same conversation I had with one of our engineers about communications library I was working on. Instead of commands, I had Request classes and then I had RequestHandlers. The design was very much like what you are describing. I think part of the confusion that you have is that you see the English word ...


2

The only question I would have is how the command service processes your commands. Are they handled asychronously or is your client waiting for the command service to process the command and complete the write to the repository before returning an ack/nack? If you're looking for scalability, that may be one area that you could focus on to improve ...


2

One thing you could do to allow a little more flexibility on the query side of things things, is define your contracts with extension points. Fowler discusses this here: http://martinfowler.com/articles/consumerDrivenContracts.html#ExtensionPoints It essentially allows you to add properties that are exposed through the service without breaking existing ...


2

If it's a system with any sort of scale involved (i.e. multiple users), you are almost certainly going to need a database. You should only need one. Databases are already designed to handle concurrency. Caching will come into play if, and when, you become the next Netflix. In other words, YAGNI (You ain't gonna need it, at least not yet). Caching is ...


2

For completeness I thought to include an relevant snippet from Martin Fowler about ways to revert state: As well as events playing themselves forwards, it's also often useful for them to be able to reverse themselves. Reversal is the most straightforward when the event is cast in the form of a difference. An example of this would be "add $10 to ...


2

I tend to resolve these naming conflicts by simply choosing different names. Perhaps you have already started calling these things by different names internally, if so, have the codebase reflect that. If not, think of something (UserCommand vs WriteCommand, Command vs Request, Action vs Command...) Basically, the overloading of the word "command" creates ...


2

First off, if that's your actual schema, it appears to be over-normalized. Hotel_Category | Categories Hotel_HotelType | HotelTypes Room_RoomType | RoomTypes Hotel_Room | Room are all candidates for being merged together by the pairing. So instead of 8 tables you would have 4. The double prefix on some of your tables is a hint that the normalization ...


2

When doing CQRS+ES I prefer not having public constructors at all. Creating my aggregate roots should be done via a factory (for simple enough constructions such as this) or a builder (for more complicated aggregate roots). How to then actually initialize the object is an implementation detail. The OOP "Don't use initialize"-advice is imho about public ...


2

I'll weigh-in with some brief thoughts. Topic 1 : Graph databases are good at modelling/querying hierarchies. Say that in your social app you want to let users know whether any of their Friends - or any of their Friend's Friends - have a birthday today. That can be an enormous query if you're recursing down all levels of Friends. A graph database should do ...


2

In my opinion, you are over-engineering the project. I think you do this because you believe you have to rely on cutting-edge techniques to handle business scale, but in many cases you will be better off relying on proven techniques and innovating only in a very focused scope. A word of caution on graph databases: in my experience, they promise more than ...


2

I would think if your domain objects on the command side are always in a valid state, you shouldn't need to worry that the queries return invalid results. What would you do, anyway, if you discovered an invalidity on the read-side, anyway? Tell the read repository to re-enter the values? ;-) If the read side were to have checking, it would think it would ...


2

The presence of a service layer does not necessarily imply the model is anemic. A service layer might provide a simplified facade to a complex domain model. I.e. a business user may just want to create a new poll. The UI is simplified if it speaks in those terms and the service layer would translate from what the UI understands into operations leveraging the ...



Only top voted, non community-wiki answers of a minimum length are eligible