多个更高层的微服务共同访问一个粗粒度的底层业务功能。这在面向“动词”的方法中是很普遍的，因为不同操作的数据需求经常会有重叠。
比如，假设系统有两个操作：更新订单和取消订单。这两种操作都要对底层的同一个订单状态进行修改，所以它们都不能排他地单独拥有这个状态。在某些情况下，我们就需要对这个冲突进行调节。在前面的例子中，order服务会处理这个问题。这个服务是应用的订单持久化状态的最终拥有者。
这种模式和鲍勃·马丁（Bob Martin）在“简洁架构”以及阿里斯泰尔·科克伯恩（Alistair Cockburn）的六角架构比较相似。在这些模型中，应用的核心由两层组成：实体——企业范围内的业务对象和规则；用例——应用中指导实体来实现用例目标的具体操作。
在这两层外面，用接口适配器(interface adapter)来将这些业务逻辑问题与应用层的实现问题（如特指的Web框架或者数据库类库）连接起来。同样，在内部服务层面上，用例（或者动作）会与底层的实体（或者存储）相互作用，从而产生一些有益的结果。然后，我们可以将它们封装在一个统一的门面（如API网关）中，将底层的服务之间调用形式映射成一种对外部消费者友好的输出结果（如RESTful API）。
从概念上看，“简洁架构”是一种优雅的架构方案，但将其应用于微服务系统时需要更加谨慎。将底层的能力视作持久化状态的存储会导致服务变成贫血的“傻瓜”服务。这种服务无法真正实现自治，因为如果没有其他更高层的服务从中对这些底层服务进行调解，这些服务就什么都做不了。这种架构方案还会增加远程调用的数量以及执行各种操作所需要的服务调用链的长度。
此方案还存在使操作与底层存储之间的耦合度增加的风险，从而妨碍独立部署服务的能力。为了避免这些缺陷，我们建议读者由内至外地设计微服务，在构建面向操作的细粒度的服务之前先开发粗粒度的功能。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论