除了设计的服务反映了与业务能力紧密相关的操作和实体，也可以通过技术能力划分。一些常见的技术能力包括与第三方系统集成以及横向跨领域的技术问题，如发送通知。
支付完成以后给客户发送一个通知，可以在支付的服务中发送。但是这种方式存在3个问题：1) 支付服务不清楚客户的联系方式和偏好信息，需要扩展支付服务的接口来支持客户的联系方式信息（由服务消费方将数据传给支付服务）或者让支付服务查询其他的服务以获取客户信息；2) 应用的其他模块如订单、账号设置、营销等，都有可能触发邮件；3) 客户可能并不想接收电子邮件——他们可能更喜欢短信和推送通知甚至是纸质邮件。
前两点表明推送通知应该是一个单独的服务。第三点表明可能需要多个服务来分别处理不同类型的通知。通知服务可以监听支付服务发送的PaymentCompleted事件。
读者可能已经意识到，通知服务还负责根据每个事件生成适当的消息内容，这表明这些通知服务的规模将来可能随着潜在的通知数量的增加而显著增长。最终可能需要把消息内容从邮件传递中拆分出来以降低这种复杂性。
以上示例表明，实现技术能力能够最大限度地提高复用性，同时还能够简化业务型服务，解除其与重要的技术问题之间的耦合。
但问题来了，什么时候使用技术能力划分服务呢？
1）在面向业务的服务中包含这个功能会使得服务过于复杂、增加未来替换的复杂度。
2）许多服务都需要的技术能力——比如，发送邮件通知。
3）可以独立于业务能力进行修改的技术能力——比如，重要的第三方系统集成。
将这些功能封装到一个独立的服务中，就可以控制那些很可能独立变化的部分，并且可以最大化提升服务的复用性。
在另一些情况中，将技术功能拆分出来则是不明智的。在某些场景中，将功能拆分出来会降低服务的内聚性，比如，在经典的SOA中，系统通常是水平拆分的，因为人们相信将数据存储从业务功能中拆分出来会最大限度地提高可用性。
遗憾的是，这种刻意为之的可重用性的代价是非常高的。将应用按层拆分会导致部署单元之间出现严重的耦合。
当要交付一个功能时，开发者需要同时修改多个应用。如果不得不在多个不同的组件中协调完成这些修改时，就很容易出错，而且会导致在部署阶段也需要确保一环套一环地依次执行上线——这彻彻底底就是一个分布式的单体。
如果首先聚焦于业务能力，就可以避免掉入这些陷阱。但是也应该谨慎仔细地划分技术能力，以确保这些技术能力真正是自治的和独立于其他服务的。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论