微服务设计要有分层的设计头脑，让各层各司其职，创建松耦合的层间关系。不要把与范畴无关的逻辑放在范畴层实现，包管范畴层的纯洁和范畴逻辑的稳固，避免污染范畴模型。也不要把范畴模型的业务逻辑放在应用层，这样会导致应用层过于庞大，最终范畴模型会失焦。如果着实无法避免，可以引入防腐层，进行新老系统的适配和转换，过渡期完成后，可以直接将防腐层代码抛弃。
那微服务之间是否也有条理依赖关系呢？如何实现微服务之间的服务集成？这些也是需要谨慎考虑的，好比有的微服务可以与前端应用集成，一起完成特定的业务，这是项目级微服务。而有的则是某个职责单一的中台微服务，企业级的业务流程需要将多个这样的微服务组合起来才气完成，这是企业级中台微服务。两类微服务由于复杂度不一样，集成方式也会有差异。
项目级微服务的内部遵循分层架构模型就可以了。范畴模型的核心逻辑在范畴层实现，服务的组合和编排在应用层实现，通过 API 网关为前台应用提供服务，实现前后端分离。但项目级的微服务可能会调用其它微服务，你看在下面这张图中，好比某个项目级微服务 B 调用认证微服务 A，完成登录和权限认证。
通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在 API 网关上的应用服务。你看下图中微服务 B 中赤色框内的应用服务 B，它除了可以组合和编排自己的范畴服务外，还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到 API 网关供前端调用，这样前端就可以直接访问自己的微服务了。
企业级微服务的业务流程往往是多个中台微服务一起协作完成的，企业级中台微服务的集成不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。
我们可以在中台微服务之上增加一层，你看下面这张图，增加的这一层就位于赤色框内，它的主要职能就是处理跨中台微服务的服务组合和编排，以及微服务之间的协调，它还可以完成前端不同渠道应用的适配，如果再将它的业务范围扩大一些，可以将它做成一个面向不偕行业和渠道的服务平台。
可以借用 BFF（服务于前端的后端，Backend for Frontends）这个词，暂且称它为 BFF 微服务。BFF 微服务与其它微服务存在较大的差异，就是它没有范畴模型，因此这个微服务内也不会有范畴层。BFF 微服务可以承担应用层和用户接口层的主要职能，完成各个中台微服务的服务组合和编排，可以适配不同前端和渠道的要求。