业务|如何从0到1实践DDD( 二 ) 使命|价值观|诚信采销|买道议

这个几个概念其实很容易理解，不过在划分的时候，注意要从业务的视角，而不是技术功能模块来划分。
2）限界上下文
我们语言博大精深，同样的话在不同语境下就可演变出不同含义，这在沟通时总是带来不必要的麻烦。为了准确地沟通，我们需要统一语言的边界，在相同的语言边界内沟通，才不容易出差错。
一则阿凡提当理发师惩罚一个狡猾牧师的趣事：理发时，阿凡提刮脸时问牧师：“牧师,是否要眉毛?”牧师答：“这还用问,眉毛岂能不要?”.“好，你要我就给你！”，说着就把牧师的眉毛刮下来递到他手里，牧师气得说不出话来，谁叫自己说要呢。阿凡提又问：“牧师,胡子要吗?”.“不要，不要！”牧师连忙说。“好，你不要就不要。” 嗖嗖几刀就把牧师的胡子刮下来。
在一个系统中，一个名词在不同语境可能有不同的含义，我们对它关注的属性和行为也有所不同。例如，在电商系统中，对于产品Product，在采购上下文，需要关注产品的进价、最小起订量与供货周期；在市场上下文中，则关心产品的品质、售价，以及用于促销的精美图片和销售类型；在仓储上下文中，仓库工作人员更关心产品放在仓库的哪个位置，产品的重量与体积，是否易碎品以及订购产品的数量。
限界上下文在《实现领域驱动设计》中，用了很大篇幅去讲，它有几个重要的意义：

限界上下文是领域概念的语言边界与业务边界：在这个边界内，领域概念的内涵是清晰、无歧义的
限界上下文是团队的工作边界：组织边界与限界上下文对齐
限界上下文是技术方案的实施边界：在这个边界内，技术方案是独立自治的，业务逻辑不会落入不同技术边界的间隙

经过战略建模之后，我们可以得到以下的一个模型：

文章插图
2. 业务实践为了更好地理解，我们对手上的一个项目：“IoT设备增值产品管理系统”进行实践。该项目中，我们提供给商户在IoT设备上管理增值运营产品的能力。这里的IoT设备主要是微信支付刷脸设备等。商户可以在系统中创建我们业务中的增值运营产品，如电子海报、互动海报等，创建完之后，相关的增值产品会被投放到IoT设备上，进行展示、运作：

文章插图

文章插图
一开始我们从业务的用例出发，认为我们的系统主要是商户在我们页面网站使用，以及IoT设备通过接口连接我们后台服务，认为这两个分属不同的子域，然后梳理了一些支撑的功能：

文章插图
画完草图之后，感觉不是很确定，于是便去咨询部门的DDD专家王老师（十分感谢王立老师的指导），得到了一些宝贵的建议：我们应该避免直接从表现层去看业务，表现层就像是冰山露在水面上的棱角，这些棱角看起来毫不相干，但是实际上底层是连成一块的，这些才是我们需要关注的。
就像这个项目，表面上商户和设备是分开的，实际上它们在操作都是我们的增值运营产品，应该看成我们的系统提供统一对外的服务，然后商户和设备来使用我们的服务。UGC内容存储业务用例其实没有涉及到的，属于实现时候的东西。一番建议让我们理清了思路，于是重新梳理，得到以下的战略建模图：

文章插图
整体而言，我们将整体系统梳理为8个子域：