3 ms·

> But when you move from the monolithic CMS to an architecture of small apps, there is no need for The Big Rewrite. Uh, what? Maybe if your app is written The

by d23 12y ago

> But when you move from the monolithic CMS to an architecture of small apps, there is no need for The Big Rewrite. Uh, what? Maybe if your app is written The Right Way, but in cases where encapsulation and cohesion are poor, where do you begin splitting? Services, on the other hand, force encapsulation from the get-go. Why wouldn't it be easier to connect them -- it's what they designed to do.

derefr 12y ago
You don't need to do a big rewrite. Instead, you 1. turn your current monolith into one service (e.g. "cms-legacy"); 2. fork the monolith codebase and remove everything not needed for that one particular component; 3. rewrite your integration tests for that component to use gateways, such that they either can be talking to the componentized service or the legacy service implementation without caring; 4. refactor the component into your favored beautiful new SOA design; 3. ensure the integration tests continue to pass; 4. remove the equivalent component implementation from the legacy codebase, and reimplement the shell of its consumer-facing API with calls to the componentized service (think LibreSSL here); 5. ensure the integration tests continue to pass; 6. repeat. Basically, this is the Big Ball Of Mud (http://www.laputan.org/mud/ http://www.laputan.org/mud/) strategy, applied to cohesion between services rather than cohesion between modules.