在微服务设计和实践中，可能很多人会一致认为：“将单体应用拆分成多少个微服务，是微服务的设计重点。”

很多人把大量的精力花费在如何拆分微服务上，并把微服务设计好坏全部归因于微服务拆分的好坏。

可事实真是这样吗？其实并非如此！

Martin Fowler在提出微服务时，提到过微服务的一个重要特征：演进式架构。

演进式架构以支持增量、非破坏的变更作为第一原则，同时支持在应用程序结构层面的多维度变化。

那如何判断微服务设计是否合理呢？

其实很简单，你只需看它是否满足这样的情形：**随着业务的发展或需求变更，在领域模型和微服务不断被重新拆分，或者组合成新的微服务过程中，不会大幅度增加软件开发或维护的成本，并且这个架构演进的过程是非常轻松和简单的。**这才是微服务设计的重点，更是微服务设计时最应该关系的问题。

在微服务设计时，很多团队在将集中式单体应用拆分微服务时，单纯按照业务功能将原来的单体应用，从一个部署包拆分成多个所谓的“微服务”部署包。这些“微服务”内的代码却仍然采用传统三层架构的设计模式，即这些代码依旧高度耦合，逻辑边界不清晰，我们暂且称它为“小单体微服务”。

三层架构：表现层、业务层、数据访问层。

在从单体架构向微服务架构演进的过程中，我们是需要边界清晰的微服务呢？还是需要很多很多的小单体微服务呢？

随着新需求的提出和业务的不断发展，这些“小单体微服务”会慢慢膨胀起来，变得错综复杂。

当有一天需要将这些膨胀的“小单体微服务”中的部分业务功能拆分出去，或者部分功能需要与其他微服务进行合并重组时，你会发现这些看似边界清晰的微服务，很难再度拆分，不知不觉中它已经变成了一个“臃肿油腻”的大单体了。这个时候你又需要一遍又一遍地，重复着大单体向小单体的重构过程，重构过程可能非常痛苦，难以取舍，甚至会让你摒弃好多之前自认为很合理的代码。

看到这里，问题已经很明显了，虽然业务边界很清晰，但是却忽略了代码边界。这种单体式微服务只是定义了一个维度的边界，即：微服务之间的业务物理边界。虽然完成了微服务架构的升级改造，但本质上依旧停留在单体架构的设计思维上，在微服务化不断演进过程中，很有可能不断会有一种反问：“微服务化真的有必要么？微服务化还不如传统单体应用呢……”

微服务设计时要考虑的，不仅仅只有微服务之间的业务物理边界，还需要定义好微服务内的逻辑边界和代码边界。

清晰的边界人人都想要，可是究竟应该如何实现呢？

DDD？