Comments on: A year in review with CQRS http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/ Wed, 08 May 2013 18:43:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: When should you use CQRS or event sourcing? » I haz teh codez http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-244 When should you use CQRS or event sourcing? » I haz teh codez Thu, 28 Feb 2013 04:47:33 +0000 http://lostechies.com/johnteague/?p=94#comment-244 [...] but I did come across this guys blog post which pretty much sums my overall views on the pattern: A Year in review with cqrs he pretty much came to the conclusion that he doesn’t use the pattern for its intent and a [...] [...] but I did come across this guys blog post which pretty much sums my overall views on the pattern: A Year in review with cqrs he pretty much came to the conclusion that he doesn’t use the pattern for its intent and a [...]

]]> By: John Teague http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-180 John Teague Wed, 22 Feb 2012 18:48:00 +0000 http://lostechies.com/johnteague/?p=94#comment-180 I really didn't want this to be all about Event Sourcing, but oh well. Yeah, I know people who use that technique to find issues too. And if you're fully distributed, I'm sure it's really helpful. But, we're not fully distributed ( and I don't think any application should be) we can capture exceptions the old fashioned way: with elmah and other log files. Plus, after a year of production use, we have 8 million records in our event store. I don't want to replay unless I have to (I'm sure you're replaying from a snapshot, but anyway) So the tl;dr; answer is it's yet another "feature" that we have not needed. But as you said I'm sure it can come in handy. I really didn’t want this to be all about Event Sourcing, but oh well.
Yeah, I know people who use that technique to find issues too. And if you’re fully distributed, I’m sure it’s really helpful. But, we’re not fully distributed ( and I don’t think any application should be) we can capture exceptions the old fashioned way: with elmah and other log files.
Plus, after a year of production use, we have 8 million records in our event store. I don’t want to replay unless I have to (I’m sure you’re replaying from a snapshot, but anyway)

So the tl;dr; answer is it’s yet another “feature” that we have not needed. But as you said I’m sure it can come in handy.

]]> By: Shane Courtrille http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-179 Shane Courtrille Wed, 22 Feb 2012 16:23:00 +0000 http://lostechies.com/johnteague/?p=94#comment-179 ES can also be a big helper when it comes to figuring out bugs.  We have it setup so we can pull from production into dev, run all events up to a specific command.  At that point we can start our debuggers up and execute the command we know failed and see why.  Not something you use everyday but when you need it.. you usually REALLY need it. ES can also be a big helper when it comes to figuring out bugs.  We have it setup so we can pull from production into dev, run all events up to a specific command.  At that point we can start our debuggers up and execute the command we know failed and see why.  Not something you use everyday but when you need it.. you usually REALLY need it.

]]> By: John Teague http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-178 John Teague Mon, 06 Feb 2012 19:26:00 +0000 http://lostechies.com/johnteague/?p=94#comment-178 My client has their own event store, so I had to use that :) I would have preferred to use, or at least experiment with, other Event Stores available (ahem..)  I think some of the issues I have are with the ES implementation.  Or at least the serialization part.  I could have extended it, but alas... My client has their own event store, so I had to use that :)

I would have preferred to use, or at least experiment with, other Event Stores available (ahem..)  I think some of the issues I have are with the ES implementation.  Or at least the serialization part.  I could have extended it, but alas…

]]> By: Jonathan Oliver http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-177 Jonathan Oliver Mon, 06 Feb 2012 19:11:00 +0000 http://lostechies.com/johnteague/?p=94#comment-177 Did you end up building your own event store? Or did you use a preexisting one? Did you end up building your own event store? Or did you use a preexisting one?

]]> By: John Teague http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-175 John Teague Mon, 06 Feb 2012 18:30:00 +0000 http://lostechies.com/johnteague/?p=94#comment-175 Like I said, this is something we did wrong. In retrospect I would either a) break up the single AR into multiple Aggregate Roots (which we will probably do) or b) find another way to use CQRS without DDD.  There were several requirements that would have been very difficult to do with a traditional n-tiered architecture using the domain model for persistence and queries. The event driven nature made some things very easy to do (more on that later). The additional layer of complexity CQRS added (or at least the event driven architecture) more than paid itself off with a reduction in complexity with our domain models and view and reporting models. I agree with you about DDD.  I think it is being overused (or at least the terminology) where other techniques would suffice. Like I said, this is something we did wrong. In retrospect I would either a) break up the single AR into multiple Aggregate Roots (which we will probably do) or b) find another way to use CQRS without DDD. 

There were several requirements that would have been very difficult to do with a traditional n-tiered architecture using the domain model for persistence and queries. The event driven nature made some things very easy to do (more on that later). The additional layer of complexity CQRS added (or at least the event driven architecture) more than paid itself off with a reduction in complexity with our domain models and view and reporting models.

I agree with you about DDD.  I think it is being overused (or at least the terminology) where other techniques would suffice.

]]> By: John Teague http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-174 John Teague Mon, 06 Feb 2012 18:26:00 +0000 http://lostechies.com/johnteague/?p=94#comment-174 1) It’s not that I want to change the values in an event, it’s that I would like to add or remove fields from the event. We’ve had several stories where we added fields they wanted to store which required a brand new event. It would have been nice to simply add the fields to the event. 2) Yes, but if I did not have the replay ability we would have functioned just fine without it. I’m sure there are domains out there where you replay frequently. This just isn’t one of them. So we did not benefit from that ability. 1) It’s not that I want to change the values in an event, it’s that I would like to add or remove fields from the event. We’ve had several stories where we added fields they wanted to store which required a brand new event. It would have been nice to simply add the fields to the event.

2) Yes, but if I did not have the replay ability we would have functioned just fine without it.

I’m sure there are domains out there where you replay frequently. This just isn’t one of them. So we did not benefit from that ability.

]]> By: John Teague http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-173 John Teague Mon, 06 Feb 2012 17:13:07 +0000 http://lostechies.com/johnteague/?p=94#comment-173 1) It's not that I want to change the values in an event, it's that I would like to add or remove fields from the event. We've had several stories where we added fields they wanted to store which required a brand new event. It would have been nice to simply add the fields to the event. 2) Yes, but if I did not have the replay ability we would have functioned just fine without it. I'm sure there are domains out there where you replay frequently. This just isn't one of them. So we did not benefit from that ability. 1) It’s not that I want to change the values in an event, it’s that I would like to add or remove fields from the event. We’ve had several stories where we added fields they wanted to store which required a brand new event. It would have been nice to simply add the fields to the event.

2) Yes, but if I did not have the replay ability we would have functioned just fine without it.

I’m sure there are domains out there where you replay frequently. This just isn’t one of them. So we did not benefit from that ability.

]]> By: John Teague http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-172 John Teague Mon, 06 Feb 2012 17:07:28 +0000 http://lostechies.com/johnteague/?p=94#comment-172 Like I said, this is something we did wrong. In retrospect I would either a) break up the single AR into multiple Aggregate Roots (which we will probably do) or b) find another way to use CQRS without DDD. There are several requirements that would have been very difficult to do with a traditional n-tiered architecture using the domain model for persistence and queries. The event driven nature made some things very easy to do (more on that later). The additional layer of complexity CQRS added (or at least the event driven architecture) more than paid itself off with a reduction in complexity with our domain models and view and reporting models. Like I said, this is something we did wrong. In retrospect I would either a) break up the single AR into multiple Aggregate Roots (which we will probably do) or b) find another way to use CQRS without DDD. There are several requirements that would have been very difficult to do with a traditional n-tiered architecture using the domain model for persistence and queries. The event driven nature made some things very easy to do (more on that later). The additional layer of complexity CQRS added (or at least the event driven architecture) more than paid itself off with a reduction in complexity with our domain models and view and reporting models.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #1037 http://lostechies.com/johnteague/2012/02/05/a-year-in-review-with-cqrs/#comment-171 The Morning Brew - Chris Alcock » The Morning Brew #1037 Mon, 06 Feb 2012 09:33:21 +0000 http://lostechies.com/johnteague/?p=94#comment-171 [...] A year in review with CQRS - John Teague takes a look back on a year working with an application architected with a CQRS style which went from inception and requirements in January, through to a first release in June, and shares the experiences of him and his team. [...] [...] A year in review with CQRS – John Teague takes a look back on a year working with an application architected with a CQRS style which went from inception and requirements in January, through to a first release in June, and shares the experiences of him and his team. [...]

]]>