限界上下文之间的关系
- 合作关系（Partnership）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
- 共享内核（Shared Kernel）：两个上下文依赖部分共享的模型。
- 客户方-供应方开发（Customer-Supplier Development）：上下文之间有组织的上下游依赖。
- 遵奉者（Conformist）：下游上下文只能盲目依赖上游上下文。
- 防腐层（Anticorruption Layer）：一个上下文通过一些适配和转换与另一个上下文交互。
- 开放主机服务（Open Host Service）：定义一种协议来让其他上下文来对本上下文进行访问。
- 发布语言（Published Language）：通常与OHS一起使用，用于定义开放主机的协议。
- 大泥球（Big Ball of Mud）：混杂在一起的上下文关系，边界不清晰。
- 另谋他路（SeparateWay）：两个完全没有任何联系的上下文
一点经历：
在之前公司 ，设计优惠/营销系统时，对于优惠条件的聚合，优惠条件的选择，优惠条件的计算等。这一系列的逻辑操作的实现上，有一点点DDD中的思想（都是回头才看到的）
- 实体:计算符定义
- 值对象：优惠条件字段对应的计算方式
- 聚合根：优惠字段的分类聚合
细节：
- 商品/订单/品牌...都有可能成为优惠条件
- 满减{减...}/满赠{赠...}计算方式/赠送礼物也不定
- 限时/限量/限用户...限制条件更复杂
总结公式： 优惠条件=何时+何人+何品牌...何价格+何优惠
实现
-
整理判断优惠条件的基础计算符号: <,>,=,!=,包含,不包含
-
整理设定优惠条件的字段：商品的品牌，订单的价格等
-
整理优惠条件场景：eg.商品：针对商品品牌，商品价格等
-
整理具体优惠方案：满足条件下的具体操作「减 价或赠送 」
定义基础的逻辑运算符，用于判断这一订单中的某些属性是否满足设定值 定义参与优惠设定的字段及对应的可用逻辑运算符，用于设置优惠时候的选项 优惠条件字段的聚合：区分出商品/订单的不同条件
创建优惠活动：
- eg.选中指定商品/或者指定品牌，选择活动时间，选择优惠方式，设置优惠值
- eg.添加聚合优惠条件：指定品牌，指定商品价格，指定订单价格...选择优惠方式，设置优惠值
验证逻辑：
