领域模型实现模式
领域模型
领域模型是一个面向对象模型，它同时囊括了行为和数据。该模式基于没有数据库前提的。
优点：创建了现实领域的业务对象，易于修改。
缺点：上手成本高，开发人员需要理解领域知识。忽略了持久化并需要依赖映射器和其他抽象方式保留和检索业务实体。
适用范围：拥有丰富业务逻辑的复杂领域，且非常重要，或者由于持续投入而经常变化的继而需要明确的某部分建模。
事物脚本
每个程序包都包含所有需要的业务逻辑，以完成工作流/业务规则和校验检查。
优点：逻辑部分都放在一个操作里面，开发人员易于掌握
缺点：逻辑一复杂，事物脚本模式就很难管理，会出现过度重复
适用范围：领域中具有很少逻辑/不具备逻辑的部分。
表模块/活动记录
业务模型和数据模型一一对应，单个对象表示数据库中的一张表
优点：业务模型和数据库模型不会出现匹配错误
缺点：业务模型和数据库模型发生分歧时，需要重构
适用范围：数据库驱动的设计/业务模型和数据模型一一对应的情况
贫血领域模型
缺点：领域对象中不包含任何行为，领域服务会承担代码更具程序性风格的角色
优点：可以转换成领域模型
适用范围：领域模型中具有较少逻辑/团队不熟悉面向对象语言。
函数式编程
函数式编程，将行为分组成聚合（领域概念）并应用于纯粹的不可变的数据结构（领域概念）。关注的是领域事件。
识别限界上下文
- 领域的专业术语和概念中存在歧义
- 要与子域和业务能力保持一致
- 团队组织和实际位置
- 遗留代码库
- 第三方集成
上下文映射
-
防腐层
-
共享内核
-
开放宿主服务
-
分道扬镳 - 人工处理/用户接口处理
-
合作关系 - 上下文集成上需要协作，发布最好一致
-
上下游关系
-
客户和供应商 - 协作性很强顾客参与供应商
- 遵从 - 没有协作，与外部供应商集成
应用DDD的原则
网友评论