From b62e4c49f48f15b403884e8697c23557c524bd4f Mon Sep 17 00:00:00 2001 From: Holger Reinhardt Date: Tue, 5 Apr 2016 22:08:08 +0200 Subject: [PATCH] Update 2016-04-01-CQRS-EventSourcing.md --- _posts/2016-04-01-CQRS-EventSourcing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2016-04-01-CQRS-EventSourcing.md b/_posts/2016-04-01-CQRS-EventSourcing.md index 2d4812a..17cc26b 100644 --- a/_posts/2016-04-01-CQRS-EventSourcing.md +++ b/_posts/2016-04-01-CQRS-EventSourcing.md @@ -9,7 +9,7 @@ author_email: frederik.michel@haufe-lexware.com header-img: "images/bg-post.jpg" --- -In these notes I would like to share my thoughts about the course I took together with Rainer Michel and Raul-Andrei Firu in London about the above mentioned topics. In this three days last November Greg Young explained with many practical examples of his career the benefits especially of CQRS and how this is related to things like Event Sourcing which is a way of reaching eventual consistency. +In these notes I would like to share my thoughts about the course I took together with Rainer Michel and Raul-Andrei Firu in London about the [above mentioned topics](http://lmgtfy.com/?q=greg+young+cqrs). In this three days last November Greg Young explained with many practical examples of his career the benefits especially of CQRS and how this is related to things like Event Sourcing which is a way of reaching eventual consistency. ### CQRS and DDD So let's get to the content of the course. It all starts with some thoughts about Domain Driven Design (DDD) especially about how to get to a design. This included strategies for getting the information out of domain experts and how to come to an ubiquitous language between different departments. All in all Greg pointed out that the software just does not have to solve every problem there is which is actually why the domain model resulting out of this is absolutely unequal to the ERM which might come to mind when solving such problems. One should more think about the actual use cases of the software than about solving each and every corner case that actually just will not happen. He showed very interesting strategies to break up relations between the domains in order to minimize the amount of getters and setters used between domains. At the end Greg spoke shortly about Domain Services which deal with logic using different aggregates and making the transactions consistent. But more often than not one should evaluate eventual consistency to use instead of such domain services as the latter explicitly show that one breaks the rule of not using more than one aggregate within one transaction. In this part Greg actually got just very briefly into CQRS describing it as a step on the way of achieving an architecture with eventual consistency.