通过领域建模识别微服务的业务功能(出售股票)

为了确定所需要的业务功能，开发者需要提高对所开发软件的业务领域的了解程度。这通常是产品发掘或者业务分析中最难的工作：调查研究，原型设计，与客户、同事或其他终端用户进行访谈等。

出售股票

为账户下单出售股票，所要交付的价值是什么？客户能够提交订单。一个很明显的业务功能是存储和管理这些订单状态。这是开发者第一个候选的微服务。

继续深入研究这个例子，开发者会发现一些应用需要提供的其他功能。为了能够出售股票，客户首先需要拥有它，所以开发者需要通过某些方式来展示客户当前持有的股份。这些股份数据是在他们账户中的交易记录所产生的。开发者的服务需要向一个代理发送订单——这个应用能够和第三方系统进行交互。事实上，发布订单这一功能需要应用支持如下的所有功能。

（1）展示当前股票的持有情况。

（2）向客户提供所持股份和订单的价值信息。

（3）将订单提交到市场上。

（4）向客户收取下单的手续费。

（5）在客户的账户记录交易信息。

（6）订单出售的钱打到对应账户上。

（7）记录出售订单的状态和历史。

我们将这些功能映射到业务能力，映射关系

开发者在开始时可以直接将这些能力映射到微服务。每个服务应该体现业务所提供的能力，这样也就能实现体积和职责的平衡。开发者还应该思考一下有哪些推动微服务在未来进行变化的因素——它是不是真的只有单一职责。比如，开发者可能认为市场操作是订单管理的子集，因此不应该分成两个服务。但是市场操作这个领域变化的驱动因素是所支持的市场的功能和范围，而与订单管理关联更紧密的是产品的类型以及进行交易的账户。这两个领域并不会同时变化。将这两块分开后，就区分了变化范围并且能最大限度地提升内聚性。

最后，牢记，了解业务领域并不是一蹴而就的过程！随着时间的推进，需要持续反复地去了解业务领域；用户的需求会变，产品也需要持续演进。随着对业务领域的了解的变化，系统本身也需要改变来满足这些要求。

---

总结，为交付有价值产品的业务功能点清单，功能点清单和业务能力的映射关系。领域建模不知道是不是指DDD领域驱动建模，书中未讲，后面也可以自行学习。

此外，业务领域了解方法包括不限于调查研究，原型设计，与客户、同事或其他终端用户进行访谈等。

了解业务领域并不是一蹴而就的过程！随着时间的推进，需要持续反复地去了解业务领域；用户的需求会变，产品也需要持续演进。

摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》