为什么迁移Z公司的monolithic system到microservices如此困难

最近在读DDD (Domain Driven Design)的内容，以前的monolithic没有遵循一些基本的DDD的原则。

As a reference 这个是另一篇DDD的文章: Domain Driven Design.

Aggregate必须遵循的三个rule的最后一个在一般的应用开发中很难遵守。我觉得基本上没有monolothic的程序开发真的遵守。一般都是把跨aggregate的操作放在一个事务里面，因为分开的话就太麻烦了，在写monolithic的时候也没人知道saga的design pattern，那如果分开的话如何保证事物一致性？很难想象有人会自找麻烦去把每一个aggregate分开成不同的事物。

分拆microservices的时候，把一个事务分开成多个事务，其实某种程度上不可避免的会影响用户体验。比如说一个大的同步call，如果分成多个事务，采用异步处理，那么用户体验会不一样。如果想要用户体验一样，所有的microservice其实最终还是要采用同步（或者异步等待）的方式，这样availability还是会受影响，各个micro service深度耦合。

这种拆开对于面向客户的应用应该还好，每个客户适应新的流程就好了。但是对于B2B来讲，客户的集成通常都是前一发动全身。而且拆分过后对于性能的影响也是不可忽略。可能觉得最后风险太大，就只能放弃。

有一个可行的方法可能是保持老的系统使用的同时，让新的用户迁移到新的系统里面。但是这里又会有新的问题，新的系统是不是完全功能兼容，而且新的系统也在不断演进，比如说拆分了一部分内容，迭代出入，然后再次拆分，迭代的时候新的客户的行为又变了。所以这种也只能是把所有行为改变的系统一起release。

他们曾经试图拆分product catalog，也失败了。Notification相对来讲是成功的，是通过新客户用新的系统，老客户用老的系统的方式来做的。比如说Order相关的notification全部都是新的架构。因为有一些东西还不完全兼容。