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

接续...

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

 

系统分析阶段 (SA)

「系统分析阶段」主要的工作是对客户的需求内容，提出解决方案并且分析系统架构。一般会采UML的配置图、套件图等等工具，来完成系统分析的工作。最终将设计完毕的解决方案，整理成一份「系统需求规格书」。

 

系统分析阶段要做的事很多很杂，甚至可以说是一种无中生有的创造过程。 经验不足的开发人员进入这个阶段，通常会不知所措。这时可以将系统分析阶段的工作，切割为不同角度来做分析设计，这也就是所谓的「视图方法」。透过视图方法去分析设计整个系统架构，决定系统架构所需要的软件分层、功能模块....等等。

 

同时也以分析设计需求分析阶段产出的领域模型，将它封装、转化成为系统架构内的功能模块。以这个功能模块为中心，再去分析设计出整个系统架构里的其它功能模块。当最后将整个系统架构建立完毕，也就完成了「系统分析阶段」该做的工作。

 

系统分析阶段 (SA) – 五视图

这个议题采用的视图方法为「五视图」，用它来划分系统分析阶段各种不同面向的分析设计工作。关于五视图相关的详细资料，可以参考「软件架构设计 - 温昱」这本着作。接下来的说明数据，就透过五视图方法去分析设计整个系统架构，来完成系统分析阶段所要完成的相关设计工作。

 

物理架构

物理架构这个面向，是要厘清整个解决方案，所整合的装置设备与联机方式。并将整理出的数据，采用「UML配置图」做分析整理的动作。藉由分析设计物理架构的工作，可以描述出整个解决方案所在的实体环境，初步定义整个解决方案的范围。

 

例如上图是一个门禁系统(Access Control Server)的物理架构数据。图中描述整个门禁系统解决方案：包含一个Acs服务器、一个Reader(卡片阅读机)、还有一个用来存放数据的Database(数据库)。并且Acs服务器与卡片阅读机采用RS485做沟通，而Acs服务器使用TCP/IP与数据库做沟通。

 

逻辑架构

逻辑架构这个面向，是要来厘清整个解决方案，所应该要开发或是整合的软件系统。并且针对应该要开发或是整合的软件系统，完成架构的分析与设计。整个逻辑架构的分析设计，又可以拆分为下列几个步骤：

 

逻辑架构 - 子系统设计

子系统设计这个步骤，是依照物理架构去分析设计，决定要将系统切割成几个子系统。并将整理出的资料，采用「UML套件图」做分析整理的动作。藉由分析设计子系统的工作，可以描述出整个解决方案所应该完成的软件系统，进一步定义整个解决方案的范围。

 

以上图来说，它是一个门禁系统(Access Control Server)的子系统设计数据。图中描述整个门禁系统解决方案：Reader(卡片阅读机)以及Database(数据库)没有开发的需求，要采用现有的系统。而Acs服务器上，则是需要开发一个Access Control Server系统。

 

逻辑架构 - 层级设计

层级设计这个步骤，是针对每个子系统做分析设计，决定每个子系统要怎么去切割软件分层。这个步骤我通常直接套用常见的三层式架构，就完成层级设计的步骤。至于会选择三层式架构的原因也很简单，因为它是在我的团队内，成员最熟悉的架构。也就是说，应该依照开发团队或是解决方案的考虑，选择一个适用的层级架构来使用。

 

以上图来说，它就是一个典型的三层式架构。Presentation Layer负责与客户做互动。Data Access Layer负责与外部系统做互动。Business Layer则是包含了上列两者之外，属于系统逻辑的部份。

 

逻辑架构 - 模块设计

模块设计这个步骤，是依照「需求分析阶段」产出的「领域模型」去做分析设计。首先依照领域模型决定核心功能模块该如何切割设计，并且将核心功能模块分发到软件分层上。再依照软件分层缺少的功能模块去做分析设计，整理出核心功能模块之外的功能模块。

 

以上图来说，它是一个门禁系统(Access Control Server)的模块设计数据。它就是很简单的将需求分析阶段产出的领域模型，直接封装成为Business Layer的核心功能模块。这边要注意的是，如果解决方案包含的领域模型较为庞大，可以依照功能或是用途来加以分类，将领域模型分割整理成多个功能模块。

 

当分析设计出Business Layer的核心功能模块，我们就可以很简单的在Presentation Layer、Data Access Layer分析设计出相对应的模块。例如：Presentation Layer没有任何功能模块，我们就加上一个用来与使用者互动的功能模块(Acs.GUI)。而因为系统需要使用RS485与卡片阅读机做沟通，那就在Data Access Layer加上一个与卡片阅读机沟通的功能模块(Acs.Messaging)。最后系统有些数据要存到数据库，那也就在Data Access Layer加入与数据库做沟通的功能模块(Acs.Data)。

 

逻辑架构 - 架构设计

分析设计到了这边，可以说完成了整个解决方案分割拆解的工作。但光是只有分割拆解，最终得到的设计成果只会是破碎零散的架构设计数据。这时要再搭配架构设计这个步骤，透过这个步骤去分析设计每个功能模块之间的互动流程、互动接口、以及加入关键性的架构模式。透过这些设计来整合每个独立的功能模块，当最后将全部功能模块整合完毕，也就完成了「逻辑架构」该做的工作。

 

以上图来说，它是一个门禁系统(Access Control Server)的架构设计数据。它在核心功能模块(Acs)与沟通功能模块(Acs.Messaging)之间，加入了IoC的设计模式。透过这个IoC的模式，定义了两个模块之间该如何互动，并且也定义了模块与模块之间的相依性。

 

当最后将全部功能模块整合完毕，也可以整理出一份功能模块之间的相依数据。

 

运行架构

运行架构这个面向，是要依照整个系统架构去分析设计，决定是否加入多执行绪的设计，并且设计功能模块之间执行绪的通讯模型。

 

以上图来说，它是一个门禁系统(Access Control Server)的运行架构设计数据。它定义了：MessagingClient这个类别收到外部来的多执行绪操作时，它会先将操作封装为委派(Delegate)交由UI执行绪(SynchronizationContext)去执行。以这样的方式去设计系统，可以让除了MessagingClient之外的系统不用去考虑Thread safety相关的设计，因为他们都是处于同一个UI执行绪(SynchronizationContext)下运作。

 

数据架构

数据架构这个面向，是要依照整个系统架构去分析设计，决定系统要采用哪种数据库，并且设计数据库是否需要备援机制、分散处理的相关议题。也决定系统要使用哪些设定档，并且设计设定文件布署位置、以及内容格式等等相关议题。另外如果系统有分布式的设计需求，也可以在这个阶段做分析设计，并在有需要的时候回头修正前几个阶段所做的决定跟设计。

 

开发架构

「系统分析阶段」最后要做的分析设计，就是决定开发相关的规则。例如：版本管理规则、项目管理规则 (项目名称、档案结构)、程序代码撰写规则 (命名空间、命名规则、例外处理、日志管理)...等等。这些开发相关的规则，会很大的影响后续产出以及将来维护的成本。能够尽早做好规范与设计，可以大大降低项目的成本与风险。

 

待续...