最近在读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全部都是新的架构。因为有一些东西还不完全兼容。

https://www.geeksforgeeks.org/domain-driven-design-ddd/ What is Domain? The word domain used in context of software development refers to business. domain logic == business logic. When we are developing software our focus should not be primarily on technology, rather it should be primarily on business (domain). Component Entity The instance of entity has a global identity and keeps same identify throughout lifespan. Identity never changes. It generally persisted as a row in DB and consists of value objects. Can we say one entity is one business object? Value Object Value Object has no identify. User is an entity and address is a value object. Services Service is a stateless class. Services is neither related…

We have been tried for so many years but since we didn’t admit we failed officially there is no formal conclusion what went wrong? Or what really made it so hard. By reading this book Microservices patterns maybe there are couple of main reasons The user interaction is very hard to change.Distribute the data to different micro services would cause that it would be more complex to complete one complex tasks. For example, when a customer want to create a subscription we potentially need to create an account, create a subscription, even doing payment, invoice and etc. Since we are B2B business it make it very hard to change the…

Data Connect Service提供同步数据到第三方。数据的change是来自数据库binlog生成的CDC (Change Data Capture)。 在系统设计中有几个挑战 Ordering的问题。前端的service并不保证顺序。那Data Connect如何保证顺序呢？技术上来讲是不可能的。但是我们可以做到在不保证顺序的情况下依然能正确处理。方法是我们从最开始的服务开始引入了Versioning的概念。如果data connect拿到的对于某一条记录的event早于之前的event，我们就丢弃。这个逻辑我们叫stale checker。这个在sync的逻辑里是可行的。比如说我们有“Create->Update”,其实对于sync，create和update都是基于Id的upsert，如果我们拿到create晚一些，就直接丢弃。同样的“update->update”也没问题，当然前提是每次我们都是拿到整个记录的full payload，不然就会有问题。我们并没有field level的versioning。 Duplication。Duplication其实我们并不太在意，因为我们的服务基本上是Idempotent的，也就是说同样的消息可以被处理两遍，没问题。原因是update本来就可以重新执行，create也可以，因为我们是根据id来的。还有就是我们有stale checker其实就能解决很多的问题。 Partition. 最开始的版本没有separate topic。我们partition by billing account id。 好处有几个 减少一个tenant占用所有的consumer的问题。当然side effect是某一些consumer会比较慢，如果一个tenant traffic比较多。 减少row locking。 控制并发。其实并发的控制我们其实可以用Resillience4j – 远程方法调用的工具箱 里面提到的同步控制机制。但是也会有负面影响。 潜在的enhance workers。我们不应该consumer thread里面处理所有的东西。应该用workers，这样就更容易scale out。问题是我们还是要保证worker的同步问题。如果有两个update对于同一个billing account，我们要保证scale checker依然可以工作。 减少tenant之间的影响。应该可以用dedicated topic来做。当然机制可能会比较复杂。我们应该还是需要common pool来出来ad-hoc traffic