软件设计不是CRUD（20）：像搭积木一样搭建应用系统（下）——微服务化系统的搭建

（接上文《软件设计不是CRUD（19）：像搭积木一样搭建应用系统（中）——微服务化系统搭建过程存在的问题》）

2、微服务拆分的基本原则

2.1、拆分后的服务设计上遵循面向对象的设计原则

在本专题开始的几篇文章中，就重点介绍了单个应用系统设计时，需要遵循的面向对象设计原则，并且介绍了在业务抽象设计过程中，如何遵循这些设计原则。在拆分后的各个服务进行设计时，照样应该遵循这些设计原则，包括单一职责、开闭性、接口隔离原则、依赖抽象、里氏替换原则等。这里本文就不展开重新介绍这些原则了，不清楚的读者可以参考本专题其它文章《软件设计不是CRUD（9）：低耦合模块设计理论——设计落地所面临的挑战》。

本文仅对这些设计原则落地时的关键效果进行描述。换个说法就是，如果一个服务的设计遵循了以上这些原则，那么就可以达到以下的设计效果。

• 保证服务内各模块的高内聚低耦合性
  遵循以上设计原则的核心目标就是保证服务内各模块的高内聚低耦合性，高内聚体现在这个服务内的所有模块都围绕一个业务点在工作，且为了完成这个业务工作服务内所有模块的联系是紧密的；低耦合体现在虽然这些模块的联系是紧密的，但是这些模块的分层却是固定的，各个模块负责的工作边界是清晰的，一个模块变化所带来的涟漪效果是可被限制的。

• 不产生循环依赖是最基本要求
  也由于这些模块已被固定的分层和模块本身具有的依赖倒转能力，所以这些模块间不存在循环依赖，甚至必要的依赖也可以做到最少。

• 较强的二次开发性要求
  好的服务被设计出来以后，是允许二次开发团队采用新增、替换、配置、扩展、编排的方式对服务的功能进行调整的。这些方式已经在前文介绍过，这里就不再赘述。需要说明的是，在服务的业务屈服度足够的情况下，二次开发团队在采用某种二次开发方式时，是不需要等待这个服务的原始维护团队发布新版本的——因为所需要的接口和配置方式在服务发布时就已经被预留出来。

需要注意的是，单个服务的设计可以通过很多设计思想来满足设计要求，例如正确运用DDD设计思想（本系列不介绍DDD思想也不介绍业务抽象设计和DDD设计的区别）。但为了保持设计思想的统一，本专题推荐读者采用业务抽象的设计思想进行单个服务的设计。

2.2、拆分后的服务是可以独立工作的

这里的独立包括两个方面，第一个方面是业务独立，这是指服务中所包含的业务功能是可以独立工作的，而不用一定依赖其它服务的业务能力才能工作。有的读者可能要问，上层服务是要依赖下层服务才能工作的，例如货运服务要完成发车的工作，就必须查询用户服务以便知晓当前司机真实姓名信息。那么货运服务怎么能叫不依赖用户服务就能独立工作呢？不是必须要有用户服务才能工作吗？这里我们需要解释一下这个具体的问题。

• 首先拥有好的设计的货运服务，依赖的用户服务并不是某种具体的用户服务，而是一个抽象的用户服务（包括抽象的模型和行为）。用户服务的具体实现可以是A也可以是B，但无论是什么