DDD不是开发人员的工具,而是系统设计的工具 - ntcoding


这是著名DDD专家Nick在FlowCon France大会上的PPT演讲,要点:
1. 一个松耦合软件架构与组织架构必须是匹配的,关键是在:持续交付效率和组织规模随着效率线性扩展。

2.一个社会技术工具集是能够更频繁实现软件交付和每次交付提升客户价值。

3. 工具集有: 依赖检查表; DDD;团队拓扑;动态重组团队和权力游戏。

4. 依赖检查表:在一个系统中选择什么时候在哪里加入组件之间的依赖,这是最基础和关键设计挑战。
依赖决策关键:

使用者不会失去任何能力;
使用者可以专注核心区域;
使用者不会被依赖拖慢;
降低冗余移除浪费;

不好现象:

使用者失去灵活使用的能力;
使用者被某个功能堵塞等待;
政治斗争;
预测假的重复冗余;

共享服务检查列表:

1. 服务使用者是否失去能力?
2. 服务使用者会获得新能力?
3. 服务使用者能聚焦他们一开始的策略战略?
4. 服务使用者是否被引入的新依赖拖慢?
5. 共享服务团队响应力如何?
6. 使用者数量有问题吗?
7. 迁移成本超支?
8. 使用者拒绝迁移?
9. 共享服务提升业务效率?消灭浪费?

领域驱动设计
事件风暴是按照时间线建模。
动作、策略和用户。
外部系统、钱和UX用户体验
事件排序策略有几种。
领域消息流
有界上下文调查表
领域故事

团队拓扑
使用DDD发现边界,作为划分组织团队的起点。
建设业务平台

重组团队
随着公司发展重组团队
工作驱动重组
因为代码需要重组
重组将人们从不愿意的位置解放。
新加入人员一般和许多团队结对

更多点击标题见原PPT

反正你让习惯了传统MVC 失血模型的开发迁移到DDD是存在不小的阻碍的,开发之前要经过培训加深了成本,CODE REVIEW成本也剧增。只看好DDD的业务分析,模块划分。

反正你让习惯了传统MVC 失血模型的开发迁移到DDD是存在不小的阻碍的,开发之前要经过培训加深了成本,CODE REVIEW成本也剧增。只看好DDD的业务分析,模块划分。