领域，子域和限界上下文
领域，子域和限界上下文
领域是一个组织所做的事情以及其中包含的一切，比如说电商的整个电商系统，它和具体的技术无关，而是这么一整套的业务流程，用DDD模型，就得先把自己这套领域搞清楚了，用面向对象的观点为其建立领域模型。
子域是整个业务系统得到某个方面，在DDD中，一个领域会被分为多个子域。子域是更加细粒度的划分，根据重要性和功能性分别分为以下三种：
-
核心子域：业务的核心，主要竞争力 -
支撑子域：支撑核心 -
通用子域：业务系统的公用部分
**限界上下文（bounded Context）**是一个显示的边界，在边界内，通用语言的所有词组和术语都有特定的含义，而模型需要准确地反应通用语言，比如说电商系统，在这么一个系统中，顾客有着特定的含义，银行系统和电商系统中顾客就不是同一个意思，因此不再一个界限上下文内。
在很多时候，我们不应该使用User这样的命名，因为这样很难在上下文中进行区分。当和权限相关时候，我们更应该命名Identity，在写作时候应该命名文Auther，在电商中应该命名为顾客。在一个领域中，不同的界限上下文之间也应该有独一无二没有歧义的命名术语。
在一个电子商务这个限界上下文中，我们可以看到多个领域模型，比如说产品，订单，物流…，我们按照实际的功能将这些交织的模型划分成逻辑上相互独立的子域，这样在一定程度上能够减少系统的复杂性。
概念映射
当需要集成时候，我们必须在不同的界限上下文之间进行概念映射。举一个例子（虽然这个例子在现实中发生的概率不高）：
一个蛋糕，从生产到送到顾客手中，它处于不同的阶段也会对应到不同的界限上下文中，
购买原料，生产蛋糕
蛋糕包装
卖蛋糕
在这些阶段中，cake包括不同的含义，第一阶段的时候可能偏向于生产，如果体现在我们代码中可能这个cake类的主要属性就是鸡蛋，黄油等
而在第二阶段可能就是纸质包装，丝带等，第三阶段就是价格，送货方式。当然这样说很粗糙，但却可以看出如果我们用单一模型来建模是多么混乱。（不小心想到前公司的order了）。要解决这样的事情，我们就应该按照阶段分为多个界限上下文，每个界限上下文有单独的cake类，表达自身界限上下文所需要的意思。而且使用这种方式，我们可以定期的，增量的交付软件。
隔离内核
当你有一个非常重要的限界上下文，但是其中模型的关键部分却被大量的辅助功能所覆盖。
筒仓效应
谷仓效应，亦称筒仓效应，指企业内部因缺少沟通，部门间各自为政，只有垂直的指挥系统，没有水平的协同机制，就象一个个的谷仓，各自拥有独立的进出系统，但缺少了谷仓与谷仓之间的沟通和互动。