DDD领域驱动设计

实体

产品愿景

我们的产品

事件

战术设计

领域建模：根据场景分析过程中产生的领域对象，比如命令、事件等之间关系，找出产生命令的实体，分析实体之间的依赖关系组成聚合，为聚合划定限界上下文，建立领域模型以及模型之间的依赖。领域模型利用限界上下文向上可以指导微服务设计，通过聚合向下可以指导聚合根、实体和值对象的设计。领域建模的参与角色：领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。

为了

产品愿景：产品顶层价值的设计，使产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。                 产品愿景的参与角色：领域专家、业务需求方、产品经理、项目经理和开发经理。

命令

战略设计

代码结构设计

分层架构及服务设计

产品愿景墙

它可以

限界上下文

而不像

业务场景：从用户视角出发的，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模。事件风暴参与者要尽可能地遍历所有业务细节，充分发表意见，不要遗漏业务要点。场景分析的参与角色：领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。

服务识别与设计：根据命令设计应用服务，确定应用服务的功能，服务集合，组合和编排方式。服务集合中的服务包括领域服务或其它微服务的应用服务。根据应用服务功能要求设计领域服务，定义领域服务。这里需要注意：应用服务可能是由多个聚合的领域服务组合而成的。根据领域服务的功能，确定领域服务内的实体以及功能。设计实体基本属性和方法。考虑领域事件的异步化处

聚合对象设计

领域对象--代码对象领域对象--代码对象领域对象--代码对象

domain:    entity    service    repostory    event

领域对象与代码对象对照清单

是一个

聚合

业务流

UML类图