实践领域驱动设计（3）- 领域

从广义上理解：领域domain 即是一个组织所做的事情以及其中所包含的一切。商业机构通常会确定一个市场，然后在这市场中销售产品和服务。每个组织都有啊自己的业务和做事方式。这个业务范围以及在其中所进行的活动便是领域。

领域、子域

领域是一个范围，包含时空的概念。

团队沟通的时候，领域可以表示整个业务系统，也可以表示某个核心域或者支撑子域。

建议使用核心域 或者 子域

在进行分工的时候，可以先划分领域，再根据划分的领域 每个成语负责一个领域的设计工作

这里领域可以和工程结构中的模块对应，这样的好处是界限清晰。分工协作。

领域模型不能包含整个业务，试图包含整个业务的领域模型非常容易失败。

对于体量小的项目来说，一个领域模型可以覆盖所用的业务，但对于中等体量的项目，产品百万，多条业务线。建议划分子域。

对于复杂的业务系统的领域划分是没有固定的标准，大多时候是一件仁者见仁智者见智的事情。

可以采用评审的方法，组织产品、开发、测试一起确定方案。

有些时候我们接触到复杂的领域模型图，理论，子域的领域模型图拼接起来便是整体的领域模型图。

个人观点：领域模型图并不是一成不变的，随着业务的发展演变，领域模型图需要随时修改，所以有时候大家会遇到领域模型和项目实际不一致的情况，原因可能是开始的时候领域专家参与了设计，后期没人维护，也可能是开发人员没有理解领域模型的设计最后没有按照设计来实现。

一个领域划分的例子：

现实中的领域和子域

领域驱动设计同时存在问题空间 和解决空间
业务逻辑的梳理和 项目的结构目录。
一个侧重业务，一个侧重技术解决方案。

或者说一个属于业务的架构一个属于技术的架构，实践中，大部分系统的业务划分由产品来完成，技术提供工程的解决方案，不同于传统的建筑行业，设计师可以天马行空，建筑工程师则立足于目前的技术实现。

建筑行业的犯错成本很高，设计方案会经过多次审核。
软件行业的犯错成本同样很高，只是大多数人感觉不大。
业务专业无法评判软件系统的优劣，产品设计可以随着项目进度修改，代价是开发返工。

问题空间是领域的一部分，对问题空间的开发将产生一个新的核心域。对问题的空间的评估应该同时考虑已有的子域和额外所需的子域。

现实中的关键点：确定核心领域

核心领域有时候不仅仅是一个。

例如 ：
一个商城系统的核心领域 ：订单、商品

理解上下文

context

界限的上下文是一个显示边界，领域存在这个边界之内
创建边界的意义：每一个模型概念 包括他的属性和操作，在边界之内都有特殊的意义，作为团队中的一员，你应该熟悉边界内的模型。

在通常情况下，我们面对的都是区别很小的概念

例如 用户、会员

一个界限的上下文并不只是包含领域模型，通畅标定了一个系统，一个应用程序，或者一种业务服务。

实践中，上下文的边界很少有人提起，默契的同事会彼此理解，如果是新的团队建议使用文字描述。

避免后期的业务划分冲突。

思考：在中小型公司，即使不适用DDD ，边界的不清楚也会导致很多不必要的麻烦，事实上，领导只是大致的划分，对于细节缺少把控，随着业务的发展，越来越多的细节讨论会使得大家效率低下。