cqrs | 易学教程

best event sourcing db strategy

阅读更多关于 best event sourcing db strategy

I want to setup a small event sourcing lib. I read a few tutorials online, everything understood so far. The only problem is, in these different tutorials, there are two different database strategies, but without any comments why they use the one they use. So, I want to ask for your opinion. And important, why do you prefer the solution you choose. Solution is the db structure where you create one table for each event. Solution is the db structure where you create only one generic table, and save the events as serialized string to one column. In both cases I'm not sure how they handle event

What is the difference between a saga, a process manager and a document-based approach?

阅读更多关于 What is the difference between a saga, a process manager and a document-based approach?

What I understand is that all three concepts are related to long-running transactions. A process manager is, to my understanding, a finite state machine which simply reacts on events and emits commands. It does not contain any business logic, it just does routing. Its goal is to bring you to a final state, where you know that your transaction has succeeded or failed. So far, so good. But now my problems in understand start: What is a saga in contrast to a process manager? There is also the document-based approach, as mentioned in CQRS sagas - did I understand them right? … as I understand it,

How granular should a domain event be?

阅读更多关于 How granular should a domain event be?

问题 I am wondering how granular should a domain event be? For example I have something simple, like changing the firstName, the secondName and the email address on a profile page. Should I have 3 different domain events or just a single one? By coarse grained domain events when I add a new feature, I have to create a new version of the event, so I have to add a new event type, or store event versions in the event storage. By fine grained domain events I don't have these problems, but I have too

Autofac resolve dependency in CQRS CommandDispatcher

阅读更多关于 Autofac resolve dependency in CQRS CommandDispatcher

问题 I'm trying to implement a simple CQRS-application example. This is a structure of my "Command" part: public interface ICommand { } //base interface for command handlers interface ICommandHandler<in TCommand> where TCommand: ICommand { void Execute(TCommand command); } // example of the command public class SimpleCommand: ICommand { //some properties } // example of the SimpleCommand command handler public class SimpleCommandHandler: ICommandHandler<SimpleCommand> { public void Execute

Akka Persistence Query event stream and CQRS

阅读更多关于 Akka Persistence Query event stream and CQRS

问题 I'm trying to implement read side in my ES-CQRS architecture. Let's say I have a persistent actor like this: object UserWrite { sealed trait UserEvent sealed trait State case object Uninitialized extends State case class User(username: String, password: String) extends State case class AddUser(user: User) case class UserAdded(user: User) extends UserEvent case class UserEvents(userEvents: Source[(Long, UserEvent), NotUsed]) case class UsersStream(fromSeqNo: Long) case object GetCurrentUser

CQRS and CRUD screens

阅读更多关于 CQRS and CRUD screens

问题 One of the basic tenets of CQRS, as I understand it, is that commands should be behaviour-centric, and have a value in the business or the UL, and not data-centric, ie., CRUD. Instead of focusing on updating a customer, we have commands like CustomerHasMoved. What if you have CRUD screens which are there to correct certain data. For example, we need to change the name of a customer which is misspelled. This doesn't really have much value in the business. Should this just be under the umbrella

How to write functionality using DDD / CQRS

阅读更多关于 How to write functionality using DDD / CQRS

I have a bank account domain as listed below. There can be SavingsAccount, LoanAccount, FixedAccount and so on. One user can have multiple accounts. I need to add a new functionality – get all accounts for a user. Where should be the function written and how? It would be great if the solution follows SOLID principles( Open-Closed principle,…) and DDD. Any refactoring that would make the code better is welcome. Note: The AccountManipulator will be used by a website client over a web service. namespace BankAccountBL { public class AccountManipulator { //Whether it should beprivate or public?

Domain Driven Design, Domain objects, attitude about Setters

阅读更多关于 Domain Driven Design, Domain objects, attitude about Setters

Been watching some Greg Young videos lately and I'm trying to understand why there is a negative attitude towards Setters on Domain objects. I thought Domain objects were supposed to be "heavy" with logic in DDD. Are there any good examples online of the bad example and then they way to correct it? Any examples or explanations are good. Does this only apply to Events stored in a CQRS manner or does this apply to all of DDD? I'm contributing this answer to complement Roger Alsing answer about invariants with other reasons. Semantic information Roger clearly explained that property setters don't

CQRS sagas - did I understand them right?

阅读更多关于 CQRS sagas - did I understand them right?

I'm trying to understand sagas , and meanwhile I have a specific way of thinking of them - but I am not sure whether I got the idea right. Hence I'd like to elaborate and have others tell me whether it's right or wrong. In my understanding, sagas are a solution to the question of how to model long-running processes . Long-running means: Involving multiple commands, multiple events and possibly multiple aggregates. The process is not modeled inside one of the participating aggregates to avoid dependencies between them. Basically, a saga is nothing more but a command / event handler that reacts

ICommandHandler/IQueryHandler with async/await

阅读更多关于 ICommandHandler/IQueryHandler with async/await

问题 EDITH says (tl;dr) I went with a variant of the suggested solution; keeping all ICommandHandler s and IQueryHandler s potentially aynchronous and returning a resolved task in synchronous cases. Still, I don't want to use Task.FromResult(...) all over the place so I defined an extension method for convenience: public static class TaskExtensions { public static Task<TResult> AsTaskResult<TResult>(this TResult result) { // Or TaskEx.FromResult if you're targeting .NET4.0 // with the Microsoft