领域模型

分层架构：

层级 作用
用户界面层 负责向用户显示和解释用户指令
应用层 定义软件需要完成的任务，指挥和表达领域概念对象来解决问题，是与其他系统的应用层进行交互的必要渠道 应用层应该尽可能的简单，不包含任何的业务规则或者知识，为下一层的领域对象进行协调任务以及分配工作
领域层 负责表达业务的概念，业务状态信息和业务规则，是业务的核心
基础设施层 为上层提供通用的技术能力，为应用层传递信息，为领域层提供持久化积滞

模式：

  • 值模型： entity，具备标识，比如订单编号，用户唯一ID
  • 值对象： value object： 关系其值，一般不会被跟踪，订单的收件人，发件人等，只是一种属性，应该是不可变的
  • 接口：service，重要的过程或者转换不是entity和value object的自然职责时，在模型中添加一个独立的接口进行操作，eg：转账，完成的购物流程
  • 模块：module，对业务进行分层处理，实现高内聚松耦合的实现

聚合（树枝与树叶）

  • factory：bean工厂，创建对象， 应该满足的两个条件
    1. 每个操作必须是原子操作
    2. 与传参进行耦合
  • repository：用于管理entity的仓库，不限定任何储存架构

领域对象的生命周期

  [*]-->activeStatus:create
  activeStatus-->repository:storage
  repository-->activeStatus:rebuild
  activeStatus-->[*]:delete
  repository-->[*]:delete

参考

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

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

常见的症状

  • 贫血症对象：仅用作于数据载体，没有行为和动作的领域对象