本文要点
如果单体是紧密耦合而不是内聚的, 就可以对其进行拆分, 以让业务更为敏捷.
有很多错误的方法可以做到这一点. 它们将带来同样紧密耦合但没有内聚性的分布式单体.
你肯定不想要这样的结果. 你希望你的服务具有内聚性, 是松耦合且自治的.
通过业务能力映射和价值链分析技术将你的技术服务和业务能力结合在一起.
如果你对 DDD(Domain Driven Design, 领域驱动设计)感兴趣, 请把你的边界上下文看作业务功能.
根据康威定律 (Conway's Law) 主动采取行动, 用它来形成最有凝聚力的组织单元.
高内聚, 松耦合和封装是 SOA 的核心特性, 同时, 这些概念本身已经测试过了, 它们真的有用.
我想读者们都很清楚为何, 何时和是否应该拆分一个单体. 但是, 为了以防万一, 给大家提个醒: 我们的共同目标是业务敏捷 https://hackernoon.com/why-you-should-split-the-monolith-e946f57db38c . 如果这个单体无法满足业务的需求, 如果开发的步伐减慢了, 那么肯定要做些什么来解决问题. 但是, 在这之前, 很显然, 你需要找出原因. 从我的经验来看, 原因总是相同的: 高耦合和低内聚.
如果你的系统属于一个单独的边界上下文, 如果它不是足够大(听起来有点模棱两可, 后面我会详细说明), 那么你要做的就是以正确的方式把系统分解成模块 https://hackernoon.com/how-to-decompose-a-system-into-modules-796bd941f036 . 否则, 你需要引入更加自主和独立的概念, 我称之为 "服务". 这个术语也许已经在整个软件行业中被用得最多的, 因此, 我要澄清一下我的意思.
来源: http://www.infoq.com/cn/articles/soa-microservices-journey