cqrs

Premise: It is recommended that in CQRS+DDD+ES style applications use task based screens, these screens guide the user and capture intent. These task screens can also be referred to as Inductive User Interface . Some examples of UI design guidelines that can help you create mondern, user-friendly apps: Microsoft Inductive User Interface Guidelines and, Index of UX guidelines The way I understand it, the tasks , generally speaking, should line up with Commands or Functions waiting on the Server. For example, if the User makes a change to the Customer's [first name], generally speaking this

I am trying to understand how to probably make use of a view model, a command and the database entity At the moment I think there is a lot of manual mapping between this, and I am unsure if I should use a tool like AutoMapper to map ViewModel <-> Command <-> Entity when there is a lot of properties (like 10-15). Take this example (written quickly in notepad, may not compile - in my real applicaiton I use dependency injection and IoC): public class Student { public int Id { get; set; } public string Name { get; set; } public string AnoterProperty { get; set; } public string AnoterProperty2 {

My application use CQRS architecture. Everything is performed through my aggregates, thus each user's action is saved as an event in my event source store. Now, I need a new form which shows the history of every action performed in my application, so what should I do ? 1 - Read the event store ? How ? 2 - Publish an event in each of my domain handler like "SavedToHistory(User user, Action action, DateTime date) then in my event handlers, store it in my read data model ? Since the whole idea of CQRS is to have separation of reading and writing, and of storage (reading vs writing again), I think

I was wondering which of my two methods is more appropriate, or is there event another one? (1) Direct Direct communication between GATEWAY and μSERVICE A UI sends HTTP request to GATEWAY GATEWAY sends HTTP request to μSERVICE A μSERVICE A returns either SUCCESS or ERROR Event is stored in EVENT STORE and published to QUEUE PROJECTION DATABASE is updated Other μSERVICES might consume event (2) Events Event-based communication via a message queue UI sends HTTP request to GATEWAY GATEWAY published event to QUEUE μSERVICE A consumes event Event is stored in EVENT STORE and published to QUEUE

I have a project which is designed or at least should be according to the well known DDD principles. Back - DDD + CQRS + Event Store UI - ngrx/store I have a lot of questions to ask about it but for now I will stick to these two: How should the UI store be updated after a single Command/Action is executed ? a) subscribe to response.ok b) listen to domain events c) trigger a generic event holding the created/updated/removed object ? Is it a good idea to transfer the whole aggregate root dto with all its entities in each command / event or it is better to have more granular commands / events for

Let's suppose we have the following: DDD aggregates A and B, A can reference B. A microservice managing A that exposes the following commands: create A delete A link A to B unlink A from B A microservice managing B that exposes the following commands: create B delete B A successful creation, deletion, link or unlink always results in the emission of a corresponding event by the microservice that performed the action. What is the best way to design an event-driven architecture for these two microservices so that: A and B will always eventually be consistent with each other. By consistency, I

I have the following scenario which I need to implement following the CQRS pattern: a user logs in the user enters some insurance details the user ask for a decision to be applied the user views the result of the decision This seems fairly straightforward, however my problem is between step 3 and 4, on step 3 I send a ApplyForDecision command which will get a decision from a underwriting service, an event with the result of that decision is then sent to the BUS for the read store to later consume it and update the view tables with the decision result. The problem is on the UI, how do I let the