微服务，和中台，完全是两回事。

1，SOA之后，应用碎片化了。如何治理这个碎片化？

2，底层对上层透明

参考IAAS，PAAS，APAAS，SAAS的分层。把碎片化服务套进去。

APAAS里面包含了一些基础服务，ELK，注册中心，消息中心等等。。。。。

使用脚手架将这些都集成，屏蔽掉，对应用透明。

这就是治理碎片化的微服务思路：将碎片化对业务开发透明，集成透明，服务透明，XXX透明，是业务聚焦于业务。不需要关注组件封装，集成等琐事。

3，分层分块的做法本质就是模块化思想

微服务的本质是领域化、模块化。

模块化思想不单单要关注拆，拆的稳定性（库），还要关注合的成本。

最终目的，是让应用开发效率提升，可用性，稳定性提升。无论是jar包，模块，paas，apaas。本质上都是一回事。是模块化思想的不同形式。

4，模块化的整合思路只有微服务一种么？不是。微模块其实会更好。

模块的形式分别是api，内置模块，jar包，soa（微服务）等。复杂度和成本是越来越高的。如果没有特别的必要，一个领域应该使用最低的复杂度去实现，不要引入不必要的复杂度。

• 每个服务，如果独立运行，成本势必很高。
• 如果打包阶段，能根据部署和链路架构，合并为一个部署模块，框架自动合并事务，化远程调用为本地调用.应用数量也要少很多。

5，微服务的问题

很多人的理解是望文生义的。直接开始猛拆。其实呢，微服务的目的是治理碎片化，而不是促进碎片化。另外，微服务架构让应用聚焦业务后，原有职责变少，复杂度降低后，应用本身应走宏服务的模式。支持的业务复杂度要比原有更“胖”一点。应用数量更少一点点。

如果没有分布式需求，就直接用springboot。别硬上SPRINGCLOUD，elk等。没必要。springboot也是微服务框架，降低组件集成成本，统一组件接口。更低使用成本等。

6，微服务和DDD的关系

该是因为DDD关于领域划分，界限上下文等描述。似的他跟貌似“拆分”的微服务搭了边。

误会大了

微服务并不倡导拆，微服务的目的是碎片化以后的治理，让基础设施对应用透明，更小成本。是一系列基础设施组件，和标准接口规范，开箱即用等理念，让应用聚焦业务。

DDD也并不倡导拆。DDD的前提是（复杂到了难以控制，拆是没办法的时候的被迫选择）。事实上,DDD的核心思想是，面对一个复杂问题是

• 抽象
• 抽象后还复杂，拆模块

领域界限上下文在第二步，没有第一步的拆分只是借了DDD招牌的拆的拆字而已，事实上如果你愿意，也可以去论语或者道德经里找有没有类似含义的字，发挥一下老祖宗的余热

微服务从外部基础设施治理复杂度。DDD从内涵上，抽象上治理复杂度。

7，微服务和中台的关系

中台是一个整体维度，他不管技术，业务，网络等等的划分。他要一个整体的工程效能结果是最有的：业务扩展灵活，实现效率快等。

微服务更关注基础设施。

要实现中台，关键是业务系统要实现参数化，配置化，扩展化，引擎化。然后再配置中心（微服务的控制面板）外再搭建一个产品中心：控制业务的配置、变更、产品扩展、验证、……事实上就是20年前提的产品工厂。

业务系统实现这四化的目标，关键是领域驱动开发。这最重要的是培养N个业务领域的懂DDD得开发。

微服务不那么难，几个技术好的就能搭好基础设施，为什么这么设计，怎么权衡，其实坑业界已经踩非常多了，技术好，技术圈消息灵通，跟进快就行。当然，即便如此，也踩了很多坑。比如对微的力度，对微的理解……等等还是会踩很多坑

业务系统领域化很难，某个业务领域要做好，需要会抽象，懂权衡的，但是无论如何权衡，抽象，其实都有可能有错误，会有很多想象不到的问题，即使技术和设计上有绝对正确的把握，但是实施、甚至操作的细节故障，会影响到上上下下方方面面的心态。。 也不一定有绝对的把握。。。。。。全部的坑都要自己踩，业务领域不像技术领域那么通用，可借鉴。。。。

并且，这是N个领域，需要N个这样更困难度的叠加，需要的人力资源和机遇要求是太高了。

这个条件，很难具备。

但是，无论如何，总结起来其实就三条

1，领域的原理、规范明确

2，大规模人才培养

2，领导决心和意志

最关键的是1。对DDD的基本概念，现在业界还是1000个人1000个哈姆雷特。DDD诞生20年来，实施效果其实不好。（大量的BAT公司其实已经非常普遍的、长时间的实践者它了），但是依然诞生了中台的需求。我觉得一个很关键点的原因是领域驱动这本书写的很含糊。

我过去15多年研发经验，早期其实已经了解DDD了，但是一直不注意这个理论没仔细研究过，只是觉得看起来还行。因为自己总结出了一套软件理论。总结出来后第一时间是激动，第二是谨慎，我希望在很多行业，不同的项目中去印证它。而且，理论最初和DDD差异还是蛮大的，在印证的过程中，发现其实我要解决的第一个问题是学习，然后是论证。。。。到最后我发现“哎呦，DDD和我蛮像的嘛，但是我一定是对他，他一定是错的……，毕竟他的拥趸实践他也有20年了，几百千个项目是有的，为嘛成功率不高？”。我刚开始一直以为DDD是错误的。于是仔细研究过他的理论。论证哪里有纰漏。这样我就出名了

首先第一我反对“领域”这个词，我认为80%的业务系统是不存在领域的，从数学上现实世界存在两种可能

1，一些事物是有清晰逻辑模型的

2，他们就是混沌的，没有清晰模型的

现实中大部分的业务系统是2，这说明DDD其实适用范围很窄。并且即使是1的情况，也不能清晰划定判别的依据和标准。

我认为领域驱动是没有给这个答案的，但是我反复研究这本书以后，我发现他是给了的。

——这就好像是打游戏，我开图玩，要很仔细的找他理论的毛病，才能发现没毛病。你们在他的体系里被绳子带着盲人摸象，更难了。

我思考这是他故意的，还是无意的。我认为这个问题不会有答案。（作者是做咨询的）——这本书的神奇之处就在于，理论的精华他都写了，但是会让你理解错误。直到最近我才搞懂为什么，原因可能不在作者。

所以，这里只是建议，学习《领域驱动》的。要有思辨，有甄别的去学习。关键是要反思自己的心态。