DDD领域驱动设计总结

领域概念

微服务首先应满足被服务的对象
领域语言是概念语言,脱离编程语言和计算机
在领域驱动设计中,每个领域的具体解决方案,可以是系统,也可以是人工完成

事件风暴

  • 事件风暴会议必须有业务专家参与,没有业务专家参与的定义领域概念必然会脱离业务
  • 事件是时间点,不是时间段
  • 每个流程必须闭合,有头事件与尾事件
  • 每个事件点,都可以用 (领域对象)已(事件动作) 的方式来描述
  • 事件是客观的,只是对发生实际事件的描述(会因人理解的差异而产生偏差)
  • 领域对象生成的依据之一是“生命周期”
  • 领域与上下文互相映射
  • 基本来说,每个上下文,对应一个微服务

结合自身工作的提问

  • 我组的核心域是?我理解是定价规则

实体与值对象区分

  • 实体可变,有变化的状态或值,有独立的生命周期,例如订单
  • 值对象不可变,不独立出现,无独立生命周期,与实体同生同死,例如订单项订单地址

系统分层

分层就像地图分层,可分为世界级,国家级,省市级,街道级,每个级别分别有每个级别的关注点
想要在一个图表示所有级别的关系是不可能或者很难被理解的,应针对每个层级创建对应的架构图

C4层级 System -> Container -> Component -> Code
参考c4
第一个是System,作者勉强用了一个System Context是为了凑4个C,不用太在意
最后一个Code层级不用深究,没有具体解释,理解为具体代码实现层即可

旧系统拆分

拆分依据

  • 业务
  • 代码变动频率
  • 人员能力

拆分方法

问题

这里有培训时同学提出的问题,也有我自己对一些以前理解不清的问题的新的理解

  • 每个微服务对应几个上下文不一定,一般来说是一对一,也可一对多
  • 以订单与订单项为例,订单为聚合根,则外部不能直接访问订单项,性能损失问题如何解决在以订单流程为核心域的系统中,应严格遵守该原则;如果是在数据分析或其他关注订单项的场景下,数据应被异构一份,
    若不异构数据,即使使用相同的表结构,根据业务核心域的定义也将不同,不应与以订单流程为核心域的系统混淆
    订单项属于值对象,一经创建即不可更改,随订单同生共死,即使有id也不是实体而是为了数据库索引而已
  • 不要定义less code系统,即希望开发者通过编写一系列定制规则,来代替写代码行为的系统,这种系统即使成功也会变成一门独立的配置语言,进而创造出新的配置语言工程师,在减少工作量上没有帮助。历史上失败的例子很多,成功的例子是SQL。
  • 通用权限系统上下文边界问题
    应只负责用户对资源是否能访问
    资源中的某些数据对某些用户可见与不可见,属于应用的业务逻辑(过滤器),不应被包含到权限系统中
    否则权限系统会与每个业务系统紧耦合,快速腐化
  • 应该用充血模型还是贫血模型老师多次提到ruby的对比,ruby内应是充血模型
    在java的世界里,已经走在贫血模型的路上了,并且没有回头的趋势

关于 admin

所有重要的进步,都来源于失败和挫折的经历
此条目发表在 未分类 分类目录。将固定链接加入收藏夹。