DDD领域驱动设计(三)

DDD实际落地

上文抽奖系统的大致需求:配置一个抽奖活动 -> 面向一个特定的用户 -> 针对特定的用户设置不同的奖品 -> 通过活动页面参与不同类型的抽奖活动

设计领域模型的一般步骤:

• 根据需求划分出初步的领域和限界content 以及上下文之间的关系
• 进一步分析每个content内部 识别出实体和值对象
• 对实体和值对象进行关联和聚合 划分出聚合的范畴和聚合根
• 为聚合根进行设计仓储。并思考实体和值对象的创建方式
• 在工程中实践领域模型，并且在实践中检验模型的合理性，倒推模型中不足的地方并重构

战略建模

战略和战术设计时站在DDD的角度进行划分。战略设计侧重于高层次、宏观上去划分和集成限界上下文，而战术设计则关注更具体使用建模工具来细化上下文。

领域

现实世界中，领域包含了问题域和解系统。一般认为软件是对现实世界的部分模拟。在DDD中，解系统可以映射为一个个限界上下文。限界上下文就是软件对于问题域的一个特定的、有限的解决方案。

限界上下文

限界上下文：一个由显示边界限定的特定职责。领域模型便存在于这个边界之内。在边界内，每一个模型概念，包括他的属性和操作。都具有特殊含义。

一个给定的业务领域会包含多个限界上下文。想与一个限界上下文沟通，则需要通过显示边界进行通信。系统通过确定的限界上下文来进行解耦，而每一个上下文内部紧密组织，职责明确。具有较高的内聚
比较合适的比喻:动物细胞存在细胞膜 导致了什么东西在细胞内什么东西在细胞外。也确定了 什么东西能通过细胞膜进入细胞

划分限界上下文

划分限界上下文。不应该按照技术架构或者开发任务来创建限界上下文。而是应该按照语义的边界来考虑。

***我的实践经验是 考虑产品所讲的通用语言，从中提取一些术语称之为概念对象，寻找对象之间的联系。或者从需求里提取一些动词。观察动词和对象之间的关系。我们将紧密耦合的各自圈在一起。观察他们内在的联系。从而形成对应的限界上下文。形成之后 我们尝试使用语言来描述界限上下文职责。看他是否清晰 准确 简捷 完整。简言之 限界上下文从需求出发。按照领域划分 ***

回到抽奖系统。使用这个系统的分为运营和用户。其中，运营角色只是配置抽奖。使用频率小。用户的话更多的是抽奖 高频率且无感知。这样就能分离出两个 分为C端和M端管理。

确定了M端领域和C端的限界上下文之后 再对其上下文进行管理。用C端用户抽奖举例。

功能如下

抽奖活动有活动限制 比如用户的抽奖次数 开始结束时间，由运营配置的
一个活动包含多个奖品。
奖品有自身的配置 概率 库存 最多被一个用户抽奖的次数。
用户群体的区别。比如按照城市。新老客户
活动风控。

首先抽奖上下文作为整个领域的核心，承担用户抽奖的核心业务。抽奖中包含了奖品和用户概念。

这里的坑。抽奖和发奖看起来也能当两个域。但是在现实中会发现逻辑是相连的分不开。决定的原因是另外一点 发奖的逻辑真的很简单 没必要单独拎出来。没必要当一个单独的服务

对于活动的限制。我们定义了活动准入的通用语言。将活动开始/结束时间，活动可参与次数等限制条件都收归到活动准入上下文中。
对于抽奖的奖品库存。由于库存的行为与奖品本身相对解耦。库存关注点更多的是库存内容的核销，且库存本身具备通用型，可以认为是一个单独的微服务。
对于C端存在的一些刷单行为或者DDOS攻击我们需要风控。用来对活动进行风控。最后活动准入、风控、抽奖都有次数的限制。还有个计数上下文。

可以看到 通过限界上下文的划分。界定出抽奖 活动准入 风控 技术 库存。这样每一个都是高度内聚的。