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

接续...

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

 

系统分析阶段 (SA)

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

 

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

 

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

 

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

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

 

物理架构

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

 

[Architecture Design] DDD经验分享 (中)_第1张图片

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

 

逻辑架构

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

 

逻辑架构 - 子系统设计

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

 

[Architecture Design] DDD经验分享 (中)_第2张图片

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

 

逻辑架构 - 层级设计

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

 

[Architecture Design] DDD经验分享 (中)_第3张图片

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

 

逻辑架构 - 模块设计

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

 

[Architecture Design] DDD经验分享 (中)_第4张图片

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

 

[Architecture Design] DDD经验分享 (中)_第5张图片

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

 

逻辑架构 - 架构设计

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

 

[Architecture Design] DDD经验分享 (中)_第6张图片

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

 

[Architecture Design] DDD经验分享 (中)_第7张图片

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

 

运行架构

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

 

[Architecture Design] DDD经验分享 (中)_第8张图片

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

 

数据架构

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

 

开发架构

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

 

待续...

你可能感兴趣的:(Architecture)