Selling EventSourcing + CQRS to Management - transition-refactor vs rewrite

[Machonky]

Hi All,

I'm testing/prototyping the viability of a CQRS approach to a complex business application. Data contention is a serious issue, so the legacy CRUD app implements a recursive-singleton R/W lock. Fine at low data volumes, but scales and performs badly at high volumes. There is a proven business need for a better solution.

With my prototypes, I can demonstrate with high certainty that a single threaded event-sourced app solves the contention issue, is scalable, performant and also leads to lock-free multithreading and high scalability downstream - an excellent outcome.

That said, selling a CQRS re-write is proving difficult in spite of obvious provable benefits. I wonder if somehow making a transition to the new paradigm would ease the sale.

Points of note:

Firstly, the legacy App was expensive - 24+ man years (6 devs), but has served a decade. 

Secondly I'd want to avoid having to maintain/extend 2 codebases during a transition from CRUD/Locking to EventSourced/LockFree so a refactoring transition might be desirable over a rewrite. In past experience, my refactored applications have won out against re-writes which were ultimately cancelled since they were always playing "feature catchup" - management couldn't justify the cost.

In any re-write/refactor the business logic would not have to be re-thought - merely translated from 1 paradigm to another.

However, I'm having trouble figuring out how I can transition the app from 1 paradigm to another. They appear to be diametrically opposed.

Advice here would be greatly appreciated.

Cheers,

Martin

[Ed Blackburn]

Can you not attempt it piecemeal? Why re-write everything? Consider updating the app to the latest version of what ever ecosystem it is now i.e. latest version of .NET, Java, Ruby make sure you're happy it runs okay (tests pass etc) and then select an aggregate. Or if you're legacy app offers no concept of this perhaps hive off a BC and start there?

Experience has left me wary of the big re-write, I've had better success chipping away at legacy apps than re-writing them. You can always have an event handler that writes to your in-situ database as you transition away from it.

Good luck!

[Ben Kloosterman]

Agree with Ed try a single aggregate that has trouble ( or even better select a medium one , once your confident tackle a high contention one ).   Dont change the whole system to Event sourcing. Mostly Static data with no logic works better in CRUD 

  

In our current very distributed system I failed to sell it first time , while I had used it before none of the other 10 had done so , eg mostly SQL /CRUD  and we had little time and i dislike architecting when the  team is not trained in an area so i caved , but we had  problems 

1. Changing data schema required changes to the synch comms contract which coupled deployments.

2.  Historical data was tracked via sql record with nullable fields which created a lot of extra data and its already a big system.

3. Data lost its business consistency when synching between nodes , this data became aggregated but had to be committed in large transactions. However we then had a bind serializable reads killed the performance ( and would get massive user complaints)  but normal transactions allowed a inconsistent read  eg while a server was being written a client would get its data and then disconnect before getting the rest of the transaction of the relevant server. 

4. More and more business logic slowing down the DB with very expensive queries eg if this hasn't occurred in 5 minutes do this , which is much better done efficiently via events or a service.  

1 & 3 were the biggest issues. 

Now they want these things fixed.

Ben

[Kijana Woodard]

I doubt you're going to be able to translate the business logic. As you've seen, simply approaching the problem from a different perspective opens up solutions that weren't available before and eliminates existing problems making various [often implicit] human procedures obsolete. It also does the reverse - new problems and closes out certain solutions.

From your post, it seems you've started noticing this already.

Agree with the others. Try to focus on a particular pain point that would benefit and re-work that. The big ball of mud is sticky, so you'll have to work to break off and isolate an identifiable chunk. It will have some ugly bits to keep everything functioning.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.