[Architecture Design] DDD经验分享 (下)

接续...

[Architecture Design] DDD经验分享 (中)

 

系统设计阶段 (SD)

「系统设计阶段」主要的工作是对设计完成的系统架构，做每个功能模块的对象设计。一般会采UML的「类别图」、「循序图」等等工具，来完成系统设计的工作。最终将设计完毕的解决方案，整理成一份「系统设计规格书」。如果说需求分析阶段是建立骨架，那么系统设计阶段就是填补血肉的工作。

 

从系统分析阶段要跨到系统设计阶段，说真的也是一种无中生有的创造过程。只不过不同的是，系统分析阶段是整个系统架构无中生有，系统设计阶段是针对模块对象要无中生有。这时候领域模型就发挥了指引的功能。透过分析设计领域模型的方式，可以有限度的将领域模型转换为核心的功能模块对象。以这个功能模块为基础去分析设计，就能设计出其它系统架构内的功能模块。当把所有功能模块都设计完毕，也就完成了整个「系统设计阶段」该做的工作。

 

系统设计阶段 (SD) – 模块设计

「领域驱动开发」定义了一组模式用来指引开发人员，将领域模型转换为的功能模块对象。关于这些模式的详细数据，可以参考「Domain Driven Design - Eric Evans」这本着作。通过这些模式可以将需求分析阶段产出的领域模型，转换为如下图的功能模块对象。

 

经过转换领域模型得到的这个功能模块对象，不会是一个独立的工作项目。这个功能模块对象也要与Use Cases、Prototype等等数据做整合，必须要可以通过功能模块对象来完整实现，与客户访谈所记录下来Use Cases、Prototype这些数据。例如说，某个Use Case内记录了客户想要「设定使用者，通过哪个门」，那在功能模块对象上就要可以透过对象模型，去找到这样的抽象描述：「使用者对象拥有卡片ID属性。将这个卡片ID属性，透过卡片阅读机对象对卡片阅读机硬件做卡片可通行设定。当卡片阅读机硬件感应到可通行的卡片，就会把门打开让使用者通过。」。当功能模块对象可以通过所有Use Case的检验，也就验证了功能模块对象的正确性。开发人员就可以安心的以这个功能模块对象为基础，去分析设计出其它系统架构内的功能模块。当把所有功能模块都设计完毕，也就完成了整个「系统设计阶段」该做的工作。

 

系统实做阶段 (Implement)

「系统实做阶段」主要的工作是将完成的系统架构设计，变成实际执行的程序代码。最终将实做完毕的解决方案，交付给客户使用。

 

基本上，只要前面几个阶段做的好，系统实做阶段就只是单纯的按图施工。但是实际上常常会遇到问题而碰壁，例如实做的平台、引用的框架不支持某某功能。这时候就要回头修正前几个阶段所做的决定跟设计，将问题点一一解决。最终就能完成整个软件、交付给客户等验收了。

 

但要特别说明的是，产出解决方案是为客户服务。但一个软件系统除了为客户服务之外，它也需要为开发人员服务。因为相关的研究显示，软件系统的生命周期，在开发完毕后的维护阶段，占了整个软件生命周期的最大部份，而负责维护的人就是开发人员。如果能够产出高质量程序代码，就可以大幅降低后续维护或是修改所需要的人力成本、减少开发人员的工作量。

 

结论

「DDD经验分享」这个议题到这边，相信大家对于这两句：软件开发流程定义做甚么、领域驱动开发定义怎么做，有一定的认知。并且知道了让软件系统的开发，不是无中生有的创造过程，而是经过层层手续跟工法生产的成果。但是就算知道了做甚么以及怎么做，最重要的还是需要动手去做。只有亲自动手下去做才会知道实做上的眉眉角角，也才能真正掌握这些开发技术。

 

参考书籍

最后，DDD经验分享这个议题，还有很多内容细节没有说明。对这些开发技术有兴趣的开发人员，可以参考下列几本的书籍，相信它们能对开发人员有所帮助。

 

- 英文书籍 : Domain Driven Design - Eric Evans
- 繁体书籍 : 写给SA的UML/MDA实务手册 - 邱郁惠
- 简体书籍 : 软件架构设计 - 温昱