常用名字解释:
- 服务自治
- 方法集成
- 领域
- 子域
- 核心域
- 界限上下文
- 通用语言
- 战术设计
- 战略设计
- 模型分离
- 上下文映射图
- 架构
- 实体
- 值对象
- 领域服务
- 领域事件
- 模块
- 聚合
- 工厂
- 资源库
- 集成界限上下文
- 优劣性
- 大泥球架构(Big Ball of Mud)
- 六边形架构(Hexagonal Architecture)
- 核心域(Core Domain)
- 支持子域(supporting SubDomain)
- 贫血领域对象(Anemic Domain Object)
- 对象-关系阻抗失配(Object-Relational Impedance)
- 限界上下文(Bounded Context)
DDD 总览
一个新的限界上线文或者上下文映射图可能需要一种新的架构.
通过战略设计(决策分配人员)和战术设计(决策DDD模型部件)而成的领域模型应该是架构中立的.
怎么做
1, 有开发卓越软件的激情和毅力
2, 渴望学习和进步
3, 有理解软件模式,并懂得如何应用这些模式
4, 有发掘不同设计方法的能力和耐性
5, 勇于改变现状
6, 看重细节,希望亲自实验.
7, 希望编写更好的代码DDD的实施,最好将那些不怎么使用技术语言的人加入到自己的团队,相互学习;
领域专家关注交付业务价值, 开发者关注技术实现
DDD本身是一种软件开发方法, 关注点如下:
1, DDD关注实用性, 通过DDD可以让开发的软件能够反映出领域专家的思维模型
2, DDD关注业务战略.战略设计通常包含战术设计,但战略设计更多关注业务战略方向;
3, 使用战术设计建模工具, DDD满足了软件真正的技术需求;DDD决策使用记分卡:
1, 系统中存在30+ 个用户故事或者用例流, 可采用DDD;
2, 软件走向模糊, 复杂度可能更加复杂. 需和领域专家一起讨论复杂性. 如果趋向于复杂功能实现,就可采用DDD;贫血症和失忆症:
1,贫血症表象:
- 领域对象主要只包含getter 和setter方法, 几乎没有业务逻辑或者完全没有业务逻辑如何DDD:
1, 通用语言的掌握识别方式:
- 同时绘制物理模型和概念模型,并标以名字和行为;
- 创建一个包含简单定义的术语表;所有想到的都罗列出来.
- 如果术语表感觉不喜欢,可以采用其他类型的文档;
- 统一团队中不同人的使用分歧;DDD带来的业务价值
- 你获得一个非常有用的领域模型
- 你的业务得到了跟更准确的定义和理解
- 领域专家可以为软件设计作出贡献
- 更好的用户体验
- 清晰地模型边界
- 更好的企业架构
- 敏捷,迭代式和持续建模
- 使用战略和战术新工具
领域,子域,限界上下文
- 领域?: 领域是一个包含众多含义的词, 领域既可以表示整个业务系统,也可以表示其中的某个核心域或者支撑子域;
- 术语?:
1, ‘顾客’:
-浏览商品目录,顾客表示放在先前购买情况,忠诚度,可买产品折扣和物流方式等 上下文中;
-下单时,顾客表示名字,产品寄送地址, 订单总价, 和一些付款术语