Episode #125 of the Stack Overflow podcast is here. We talk Tilde Club and mechanical keyboards. Listen now

Hot answers tagged

90

You seem to suggest that the complexity of an interface is measured by the number of elements it has (methods, in this case). Many would argue that having to remember that the charge method can be used to return the balance of a Client adds much more complexity than having the extra element of the getBalance method. Making things more explicit is much ...


28

IMO, replacing getBalance() with charge(0) across your application isn't a simplification. Yes it is fewer lines, but it obfuscates the meaning of the charge() method, which could potentially cause headaches down the line when you or someone else needs to revisit this code. Although they might give the same result, getting the balance of an account is not ...


21

The following answer is in the context of the CQRS style promoted by the cqrs.nu in which commands arrive directly on the aggregates. In this architectural style the application services are being replaced by an infrastructure component (the CommandDispatcher) that identifies the aggregate, loads it, sends it the command and then persists the aggregate (as a ...


18

Since you tagged your question with "CQRS", I guess you mean events in a "CQRS & Event Sourcing" context, like it is described here. In this tutorial, the difference between events and commands is well explained: events capture the elementary "things that can happen" in your system, from the system's point of view. commands are defined by what the user ...


18

In the first case (shut-down of VMs), I'd consider none of the OP alternatives RESTful. Granted, if you use the Richardson maturity model as a yardstick, they are both leve 2 APIs because they use resources and verbs. Neither of them, though, use hypermedia controls, and in my opinion, that's the only type of REST that differentiates RESTful API design from ...


18

I sketched my rough understanding on how an ES / CQRS app should look like contextualized to a simplified banking use case (withdrawing money). This is the perfect example of an event sourced application. Let's start. Every time a command is processed or retried (you will understand, be patient) the following steps are performed: the command reaches a ...


17

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 ...


17

Is CQRS a relatively complicated and costly pattern ? Yes. Is it over-engineering ? Absolutely not. In the original article where Martin Fowler talks about CQRS you can see a lot of warnings about not using CQRS where it's not applicable: Like any pattern, CQRS is useful in some places, but not in others. CQRS is a significant mental leap for all ...


15

First, it is important to understand and be able to leverage the difference between Commands and Events. As this question succinctly points out, Commands are things we would like to happen, and Events are things that have already happened. A command does not necessarily result in a significant event in the system, but it usually does. For example, a send ...


14

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 "...


14

What is "eventual consistency"? How does it compare to "transactional consistency"? When does it happen? Consistency models describe how a system (nominally a distributed system) responds to change. In an eventually-consistent system, all nodes will eventually have a consistent view of the overall system state. However, there will be a period of time after ...


14

In principle, a command describes a request that is to be executed, whereas an event describes something that has happened: A command requires some action to be performed by a processor, and this action should be performed only once by this processor. An event is the notification of some action that was already executed or an external happening. Several ...


13

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 ...


13

The idea in Udi's post, as I gather, is that no kind of item appears out of thin air. There is (almost) always something, or more specifically, some domain operation, which caused the item to be created. Just like Udi's example of a user actually being born out of a visitor registering to the site. At that point and at that bounded context Visitor is the ...


13

It's important to remember that your code should be self-documenting. When I call charge(x), I expect x to be charged. Information about balance is secondary. What's more, I may not know how charge() is implemented when I call it and I definitely won't know how it's implemented tomorrow. For example, consider this potential future update to charge(): float ...


13

Review what Rinat Abdullin wrote about evolving business process. In particular, notice his recommendation for developing a business process in a fast changing environment -- a process manager is "just" an automated replacement for a human being staring at a screen. My own mental model of a process manager is that it is an event sourced projection that you ...


13

What I'm not super clear on is why you would ever rehydrate your Aggregates from the Event Store itself. Because the "events" are the book of record. If projecting changes to "read" databases is so easy, why not always project changes to a "write" database whose schema perfectly matches your domain model? This would effectively be a snapshot database. ...


12

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 ...


12

CQRS and DDD are separate/orthogonal concepts, and I think you divided the terms pretty close to right. Events under DDD are called Domain Events, and are somewhat different from the Messaging events often mentioned with CQRS. Messaging events usually have more to do with Event Sourcing. Your CQRS category is a conglomeration of a number of patterns, and ...


12

How do I deal with side effects in Event Sourcing? Short version: the domain model doesn't perform side effects. It tracks them. Side effects are performed using a port that connects to the boundary; when the email is sent, you send the acknowledgement back to the domain model. This means that the email is sent outside of the transaction that updates the ...


11

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 ...


11

In retrospect, I think I was complicating the issue. In general, commands should either throw an exception or raise one or more events. If I could summarise the architecture of Event Sourcing it would be as follows: Commands are inputs representing instructions to do something. Events are outputs representing historical facts of what was done. Event ...


10

This is like asking if you can use utensils to eat ice cream. (Yes you can. I recommend a spoon.) CQRS asks you not to mix together the complexity needed to perform queries with the complexity needed to update. Hexagonal Architecture asks you not to mix the complexity of your input and output ports with your central application logic. So yes you can do ...


10

Let's start with a short review of the problem-space here. The fundamental benefit of adopting a CQRS pattern is to solve/simplify your problem domain by reducing the interleaving and leakage that begins to occur when utilizing the same model for your write-side as your read-side. Often, the tension that arises serves as a detriment to both. CQRS seeks to ...


9

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 ...


9

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 ...


9

Usually one command will lead to one event. But in some cases it can also be more than one, it depends on your implementation. Either your command calls other commands and each of them fire own events. Or your command does different tasks on it's own and issues multiple events. For example: RegisterUserCommand User.create(email, password) → ...


9

One command can raise multiple events. It is simply logical conclusion of one fact : Composite command exists. Lets say you have two commands, each raising an event. Then, you create a composite command of those two. From the view of one using the composite command, it seems as if the command raised two events. So there is nothing stopping you from having ...


9

Well they are three separate things and they are real things not just buzz words. But.... Domain Driven Design. I've seen this used quiet commonly now, at least in a 'lite' fashion. I think it does help to define and break down a system into component parts. Command Query Segregation. Although there are cases where you want to have a read only db and a ...


8

(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 ...


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