关于微服务架构

这道题的作业是对中台架构、领域驱动设计、组件设计原则的理解。我从组件设计原则和领域驱动设计和中台架构的顺序来讲。

组件设计原则

组件内聚，一个组件肯定是内聚一起的，有一定的原则：

复用发布等同原则，别人用你组件的最小粒度发布。比如一套家具可能有椅子有桌子有沙发等等。别人经常用椅子粒度，那么你可以把椅子当成一个组件的粒度。

共同封闭原则：经常会把同时修改的内容放到一个组件中。这个原则放到所有的组件中，你就会发现之前所学习的开闭原则很像。修改的内容对其他的组件的影响比较少或者没有没有，这样才是最好的

共同复用原则：不要强迫一个组件依赖于他们不属于的东西。在实际工作中你就会发现有时候写个类，发现别的组件已经写过这个类，你不要因为赖直接引用这个组件里面的类，而是重新写一个。或者把别的组件的这个类考虑是否放到 common 组件中。

组件中间免不了耦合，耦合还是有些注意事项：

无限循环依赖：这个一般会有版本发布不同步，造成这种现象。在实际工作就是某些业务优先级比较高，又着急上线很容出现本来版本组件 A 和 B 版本不一致，本来是 A 依赖于 B 版本。结果 B 版本因为业务比较急发了一个新的版本，依赖于 A 的旧版，出现了循环依赖。

稳定依赖：这个很好理解，一定是不稳定依赖于稳定。就像盖房子，地基越稳定房子就会越牢靠

依赖抽象：这个也很好理解，比如 java 的 jdbc 接口。sun 公司定义一批 jdbc 接口连接数据库，剩余都有厂商来实现这些接口，开发人员开放的时候直接对着接口编程就可以了。底层的数据库是哪个厂商就用哪个厂商的包就可以了。

领域驱动设计：

我觉得领域驱动设计是目前来说我遇到最好的设计，没有之一。强烈的关注业务根据业务来划分领域，这个比较好，这个既能把业务人员，产品人员，开发人员，实施人员等等不同的人联系在一起，每个职业不同的人提出自己的关系，可以看到不同职位的人思考方式不一样，对业务的理解也不一样。可以全部理解业务，这样开发人员做出来的东西不会偏离业务，至少不会做无用功。同时业务也是企业的生存之本，业务才能赚钱，赚钱公司才能生存。领域驱动把业务划分成领域，领域又有子领域，在子领域中定义一套名字，在这个子领域中保持含义相同，这样也保证沟通交流的有效性，防止用不同名字表达相同含义时，在不同的人理解有偏差。同时关注一个个聚合，然后就是实体，值对象。站在上帝视角，看待整个业务，最终把每个业务细分到一个个实体，一一对应，让开发，业务，产品都能明白。以后也易于维护。

之前按照实体业务，设计数据字典，然后通过数据字典开发业务，出现数据库驱动业务开发，这样的开发出现的问题，当业务继续增加，数据库进行修改，然后代码的修改出现混乱现象，也很容易出现问题。慢慢开发一段时间之后，维护也会变得困难。

中台架构

中台架构其实是业务发展到一定程度上，发现很多复用的组件，可以提供服务。也就是你的服务有了一定基础才会去搞这个中台，很多时候刚开始就上中台服务，我觉得是不合适，比如业务刚开始从 0 到 1 的阶段，这个时候应该以业务为主，这个时候做中台架构我觉得有点超前，很可能做很多无用功。

中台现在还有业务中台，数据中台，技术中台。其实就是一种组织架构，比如航母一样，提供基础平台，有了这个平台，上面可以停放各种战斗机，侦察机，火箭导弹等等。