易广军，朱赵辉,2，孙建会,2

（1. 北京中水科工程总公司，北京 100038；2. 中国水利水电科学研究院，北京 100038）

应用领域驱动设计实现大坝安全监测复杂业务

易广军1，朱赵辉1,2，孙建会1,2

（1. 北京中水科工程总公司，北京 100038；
2. 中国水利水电科学研究院，北京 100038）

通过领域驱动设计，合理地分离领域知识，用软件开发人员和领域专家都能理解的统一模型表达业务逻辑，相比传统的数据驱动开发模式，使大坝安全监测软件中的核心业务脉络清晰，易于扩展和维护。实际应用效果证明该方法设计的领域模型能够很好地适应需求的变更和新功能的增加，有利于实现大坝安全监测复杂业务的自动化处理。

大坝安全监测；领域驱动设计；领域模型

0 引言

随着全国水利工程建设持续、稳定的发展，因旱涝而引起的自然灾害有所减少，生态环境逐步得到改善。但新建工程的不断增多，也给工程施工质量管理及运行安全保障工作带来了挑战。安全监测作为掌握水利工程各建筑物工作状态，反馈设计、指导施工的主要手段之一被广泛应用。近些年来，在水利信息化集成企事业单位和仪器厂商的推动下，有关安全监测的信息化系统也在不断地改进完善，数据的采集、存储、处理、分析等功能日趋成熟。但总体来看，仍存在复杂业务需求不能满足，对用户专业水平要求过高，自动化处理程度较低等诸多问题。究其原因，主要是采用了以数据库为中心的数据驱动开发模式。这种模式虽然可以快速实现项目目标，但从根本上制约了面向对象技术的使用，很容易使项目陷入困境，原因如下：

1）概念不清。在设计和开发阶段，没有统一的概念定义，经常出现需求文档和开发文档对同一元素理解的不同，开发人员专于技术，常以自己的理解完成代码的编写。

2）需求设计文档难于理解。由于需求分析和设计的分离，模型边界不清，关系复杂，开发人员在参考相关资料时不能抓住设计重点，以致避重就轻地实现而出现不同程度的曲解。

3）代码复杂。由于没有对象的封装或有对象而认识不统一，多个业务的重合部分以不同方式实现，或基础架构与业务逻辑混杂，造成理解的困难。

4）适应需求变化能力差。当需求变化时，可能要修改数据表，这时新增的字段和业务逻辑将造成大量的修改，很容易使设计文档与代码不一致。

5）复杂业务难以开展。随着业务功能的不断实现，整个项目进入一个不断修正的怪圈，很可能牵一发而动全身，使项目最终陷入高代价的维护之中。

针对这些情况，提出应用领域驱动设计（Domain-Driven Design，DDD）[1]方法解决大坝安全监测领域的复杂问题。领域驱动设计摒弃了分裂的分析和设计方法，使用单一的领域模型满足分析与设计 2 方面的需求。领域模型是软件项目的公共语言核心，术语和关系反映了领域的深层次含义，将这些术语和关系作为模型语言，可保证开发人员与领域专家对用户需求有一致的、精确的认识。领域模型设计通过一系列的柔性设计模式，将潜在的概念显式地展现出来，使开发人员可以灵活地使用一个最小的、松散耦合的概念集合表示领域中的复杂场景，然后通过重构和精炼，将混杂在一起的组件分开，专注于模型中最有价值的部分，然后重构得到更深层次的理解。

1 领域驱动设计相关理论

1.1 领域模型

领域模型是软件项目的公共语言核心。模型语言中有关项目的概念将模型和开发活动结合在一起，并使模型和代码紧密地绑定[2]。在基于模型的交流中，开发者和领域专家并不仅仅局限于 UML（统一建模语言）图进行，而是充分利用各种手段，讨论需求、开发计划和特性，确保团队中所有交流活动和代码中坚持使用一致的语言，积极消除难点，然后重构代码，并对类、方法和模块重新命名，形成公认的理解。

领域模型要求开发人员和领域专家使用模型的元素及模型中各元素之间的交互描述业务场景，并按照模型允许的方式将各种概念结合到一起，找到更简单的表达方式讲出自己的观点，然后将这些新的思想应用到图和代码中。在交互图演示复杂业务场景时，要将相关的约束和断言加进来，若是 UML图就要用文本说明，不留任何存在歧义的死角。

领域模式与设计模式相比有以下非常不同的关注点[3]：如何进行领域模型本身的结构化；如何在模型中封装领域知识；如何应用通用语言，并且不使基础架构分散对领域核心的注意力。

总之，软件系统各个部分的设计应该如实地反映领域模型，以便体现出这两者之间的明确对应关系，不仅如此，反复的检查和修改模型是很有必要的，最终形成的设计应该更加自然地描述模型，反映出深层次的领域概念。从长远来看，以领域模型为核心的设计更加清晰，也更忠实于领域抽象的实现，因而可维护性很高。

1.2 领域分离

为了保证软件实现的简洁并与模型保持一致，不管业务如何复杂，必须运用建模和设计的最佳实践将领域设计与软件系统中的其它关注点分离，才能使设计与模型之间的关系非常清晰。

分离领域的复杂技术早已出现，领域模型采用的分层基本原则是层中的任何元素都仅依赖于本层的其他元素或下层的元素，向上的通讯必须通过间接的传递机制进行。典型的分层模式示意图如 1 所示，各层具体分析如下：

图1 领域模型的典型分层结构

1）用户界面层。或称表示层，目标是尽可能地薄，绝对不允许在该层嵌入业务逻辑，所以该层只须履行解释用户的操作，有将消息发送到应用层或领域层及向用户显示信息 2 个主要职责。

2）应用层。应用层可以作为系统应用编程接口（API），是与其它系统进行交互的必要渠道，不包括业务规则或者知识。无论是 C/S，还是 B/S 的表示层，都可以很方便地实现数据的获取和保存。除此之外，该层还用于协调领域对象之间、领域对象与基础设施对象之间的动作，维护特定任务状态并为用户显示任务进度等。

3）领域层。领域层负责表达业务概念、状态信息和规则，而不关心保存业务（由基础设施层实现）状态的技术细节，即使用 POCO（Plain Old CLR Object，简单传统 CLR 对象）的方法设计，领域模型不必实现持久化相关接口或从业务无关的类继承，确保与持久化无关。

4）基础设施层。为以上各层提供交互支持，如应用层的消息传递，领域层持久化机制实现，用户界面层的屏幕显示等。

分层的价值在于每一层都只代表程序中的某一特定方面。领域对象将重点放在表达领域模型上，能有效地捕捉并使用基本业务知识，不需要考虑自己的实现和存储问题，也无需管理应用任务等内容，以便保持含义足够丰富、结构足够清晰。彼此独立的层更容易维护，因为它们往往用于满足不同的需求。这种模式使每个方面的设计都具有内聚性，更容易解释，并被理解。

2 大坝安全监测领域模型分析

目前在大坝安全监测系统应用过程中，如果出现新需求，系统无法合理解决时，往往采用以下折中的处理方式：1）在系统中进行配置，使用原有的业务逻辑基本满足新需求；2）维护程序源码，增加新的业务逻辑，但需要进行单独处理。这 2 种解决方案，虽然基本能满足用户的功能需求，但都在一定程度上歪曲了需求或系统原有面貌，改后的系统出现了不同于原有设计“通用”的认识，使业务逻辑不清晰，甚至难以理解。而 DDD 是由业务问题控制解决方案的形式，问题领域的简化视图可以非常接近于面向对象的对象模型，分层模式如图 2 所示。

图2 大坝安全监测领域模型的分层模式

对照图 2，大坝安全监测系统的领域对象包括大坝建筑物及其部位，依据仪器布置原则而设置的监测面、线，依据监测目的需要而设置的测点、仪器组（或称测点集），以及测点所使用的仪器。建筑物及其部位、监测面、监测线、测点集统称为“监测对象”，围绕这些领域对象，对部分业务需求进行分析，以 F + 序号的方式列举如下：

F1 表示建筑物及其部位的层次关系，监测线、面与测点之间的关系。

F2 表示核心业务围绕监测对象展开，如绘制过程线图、相关图、分布图、等值线图，查看考证表，记录计算表、统计表等。

F3 表示 1 个测点可以有多种观测方式，且在不同时段可以有不同的参数或计算公式，如 1 个扬压力测点既有压力表的人工观测值，也有扬压力计的测值，某时刻可能因传感器损坏而进行了更换。这时，观测方式的不同带来观测物理量和测值转换计算的不同，更换仪器也会引起计算参数或公式的改变，形成复杂的需求。

F4 表示测点集需要计算新的物理量，并可按单一测点的绘图样式作图。

F5 表示观测计划的跟踪和监督。每类监测项目都有观测频次，应按提交的计划跟踪实施。

为了获得灵活的模型，必须梳理好它们之间的关系。通常，建筑物或部位包含监测面、监测线、测点，在监测面上布置有测点，也有按桩号（或轴距、高程）布置的监测线；1 组测点可以定义为监测线或测点集，所不同的是测点集可以通过测点测值的联合计算获得需要的监测物理量（如应变计组通过各测点联合计算获得单轴应力）。

领域对象的关系和约束可用如图 3 所示的领域模型表示，分析如下：

1）用监测对象实体表示建筑物及其部位、监测面、监测线和测点集。由于测点不仅有自身安装埋设相关信息，还包括所使用仪器的厂家参数等，所以将测点独立作为 1 个实体。

2）监测对象可以有多个子监测对象，也可以有多个测点（如环境量测点安装埋设在某建筑物或部位）。

3）测点可以属于不同的监测对象（如 1 个测点既在纵断面上，又在横断面上）。

4）测点使用多种观测方式观测，每种观测方式使用 1 种仪器。

5）所有监测对象不必关心增加、删除、修改、查询的具体问题，直接由存储器接口处理。

图 3 给出了 1 个统一的模型，可以清晰地表达大坝安全监测系统中的以下业务需求：

1）对于 F1 的需求很容易由领域模型得到满足。领域模型将建筑物和测点分开作为 2 个重要的实体，确定了从属关系。同时，在监测对象中预定义了测点在布置图中位置的属性，方便了在布置图上显示测点及最近测值、测点状态、测点级报警信息等内容。

图3 大坝安全监测领域模型类图

2）建筑物及其部位、监测面、监测线、测点集均继承自监测对象，保证了统一的处理过程，并按监测对象分配不同的业务过程，如监测面上可以绘制等值线图，监测线上可以绘制分布图、多测点沿某一位置坐标变化的分布图、多测点与某一环境量的相关图，测点集上可以绘制其联合计算的物理量过程线图、相关线图、统计模型分析成果图等。图表分析从单个测点到多个测点的设计思路，保证了复杂业务对简单业务的组合使用，做到了代码的复用，很容易通过选择某一监测对象实现所有测点的数据和图表的批量导入、导出，并自动形成初步分析报告。

3）设计安全监测自动化系统的基本原则和功能要求中明确指出：系统应有人工观测接口，以便在系统完建之前或发生故障时，进行人工补测；在系统正常运行时进行校测[4]。从目前大坝安全监测实际情况来看，仪器参数、测点基准值、公式的变化经常发生，多种测量方式也在很多监测项目中存在，如某一渗流量观测点前期采用量水堰堰顶测针观测，后期采用量水堰计观测，观测方式的不同带来了观测数据、相应参数、公式的存储问题，以数据库为中心的开发往往在“发现”这个需求后，以增加、修改表来适应，会造成系统的不稳定，如更改后的系统不能如第 1 版进行全面测试，经常出现系统崩溃的问题。领域模型为了满足 F3 的要求，引入“观测方案”和“方案项”2 个重要的实体，当增加新的观测方式时，可以增加 1 个方案；当由于仪器损坏更换了仪器，参数、公式变化时，可以增加1 个方案项。这种处理方式恰当地解耦了业务的复杂关系，便于扩展和维护。

4）测点集除了有监测面、线的特性外，还有自身的特点——计算新物理量，如三向测缝计、五向应变计、七向应变计等，测点集可以由多个测点组成，形式上更加灵活，即使以后增加了更多向的仪器，也能用现有结构适应，不用修改数据库或源码，满足 F4 的实际需求。在研究领域模型中，测点集代表通常所说的“仪器组”，而呈线性布置，不联合计算新物理量的 1 组仪器定义为监测线，如引张线、静力水准等系统均是监测线。这样，改变了传统模糊的理解，使概念更加清晰，方便设计与实现。

5）关于 F5，现有大坝安全监测软件中均未涉及，那是否可以说明不重要？答案是否定的。通过考察长江三峡、向家坝、白鹤滩等大型水利工程发现：大型工程，存在参建单位多，全面监督难的问题，由于工程或管理问题出现数据缺失的情况不在少数。所以，为了保证数据获取的及时、有效，观测计划的监督实施，无论是在施工期，还是运行期都十分的必要。在大坝安全监测领域模型中，将计划追踪放在方案项中，在出现缺测、漏测的问题时可以进行报警，及时将观测情况报告给管理者。

3 结语

通过分析业务场景，运用领域驱动设计解耦领域中的复杂关系，使开发人员和领域专家在统一认识的基础上，不断精炼领域知识，重构领域模型，最终构建 1 个单一的大坝安全监测领域模型。该领域模型摒弃了传统数据驱动开发中表间关系的复杂性，不仅能够方便地实现基本的业务需求，而且对复杂业务也融合得恰到好处，在工程实际应用中，对需求增加、变更的适应性很强，大幅降低了开发难度，减少了测试时间。但毫无疑问，领域驱动设计在大坝安全监测软件开发中的应用仍处于探索阶段，缺少对更深层次问题的探讨，希望能够引起更多领域专家对基本的领域模型的重视，积极参与到软件系统的设计中来，改变大坝安全监测系统软件由软件人员主导的现状，减少操作复杂性，不断提高自动化程度。

[1] Eric Evans. 领域驱动设计——软件核心复杂性应对之道[M]. 赵俐，盛海燕，刘霞，译. 北京：人民邮电出版社，2010: 16-17.

[2] Tim McCarthy. .NET Domain-Driven Design with C#: Problem-Design-Solution[M]. Hoboken: Wiley Publishing Inc, 2008: 5-10.

[3] Jimmy Nilsson. 领域驱动设计与模式实战[M]. 赵俐，马燕新，译. 北京：人民邮电出版社，2009: 22-28.

[4] 国家电力监管委员会大坝安全监察中心. 岩土工程安全监测手册[M]. 3 版. 北京：中国水利水电出版社，2013: 132-150.

[5] Martin Fowler. 企业应用架构模式[M]. 王怀民，周斌，译.北京：机械工业出版社，2011: 10-12.

[6] Erich Gamma, Richard Helm, Ralph Johnson, et al. 设计模式——可复用面向对象软件的基础[M]. 李英军，马晓星，蔡敏，等译. 北京：机械工业出版社，2013: 120-128.

Application of Domain Driven Design in Complex Business of Dam Safety Monitoring Software

YI Guangjun1, ZHU Zhaohui1,2, SUN Jianhui1,2

(1. Beijing IWHR Corporation, Beijing 100038, China；
2. China Institute of Water Resources and Hydropower Research, Beijing 100038, China)

Through the domain driven design, reasonable separation of domain knowledge, the article uses a unified model that software developers and domain experts can understand to express the business logic. Compared with the traditional pattern of data driven development, it makes the core business of dam safety monitoring software clear thread, easy to extend and maintain. Effect of practical application proves the domain model of the method designed is able to adapt to the change of demand and the increase of the new features, advantageous to realize the automation of complex business processing.

engineering safety monitoring; domain driven design; domain model

TV698

A

1674-9405(2015)04-0052-05

2015-06-02

易广军（1980－），男，陕西西安人，工程师，研究方向：岩土工程安全监测软件系统设计与实现，水库安全鉴定评价。