基于领域驱动设计的大坝安全监测信息系统

易广军，贺　虎，2，孙建会，2（.北京中水科工程总公司，北京，00038；2.中国水利水电科学研究院，北京，00038）



基于领域驱动设计的大坝安全监测信息系统

易广军1，贺虎1，2，孙建会1，2
（1.北京中水科工程总公司，北京，100038；2.中国水利水电科学研究院，北京，100038）

摘要：针对传统数据驱动开发模式的局限性，提出通过领域驱动设计，合理分离大坝安全监测的领域知识，用软件开发人员和大坝安全监测专家都能理解的统一模型表达业务逻辑，使大坝安全监测信息系统中的模块耦合度降低，核心业务脉络清晰，更好地适应需求的变更和功能的扩展。

关键词：大坝安全监测；领域驱动设计；领域模型

0　引言

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

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

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

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

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

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

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

1　领域驱动设计相关理论

1.1领域模型

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

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

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

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

1.2分离领域

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

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

图1　图领2.1域 领模域模型型的的典典型型分分层模层式模式Fig.1 Typical hierarchical model in domain model

1.2.1用户界面层或称表示层

该层的目标是尽可能薄，不允许在该层嵌入业务逻辑，所以该层只需履行两个主要职责：一是解释用户的操作，将消息发送到应用层或领域层；二是向用户显示信息。

1.2.2应用层

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

1.2.3领域层

负责表达业务概念、业务状态信息和业务规则，而不必关心保存业务（由基础设施层实现）状态的技术细节，即该层将使用POCO的方法设计，领域模型不必实现持久化相关接口，确保与持久化无关。

1.2.4基础设施层

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

从竖炉熔铜过程分析不难看出，其装料、熔化、升温及后续保温各阶段热负荷的需求状况及热传导方式差异很大，唯有针对以上特点，加强竖炉故障分析及过程控制，方能实现SCR型燃气竖炉的最优化效果。

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

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

由于大坝安全监测领域知识专业性强，涵盖面广，所以需要找到一个切入点开始领域知识的提取和业务逻辑的梳理。大坝安全监测设计作为一项综合的工程技术，正是所找的切入点。它以现场地质条件、环境条件及建筑物间的相互作用为基础，充分考虑工程的复杂程度、荷载、开挖规模以及由此产生的不利后果的潜在因素，从确定监测目标开始，直到获得数据资料、进行分析评价为止，贯穿安全监测的整个环节。

2.1大坝工程条件分析

大坝安全监测系统的确定和建立取决于实际工程的条件，如不同的类型（混凝土坝、土石坝）、不同的结构型式（混凝土坝分为拱坝、重力坝、支墩坝；土石坝分为均质坝、心墙坝、面板坝等）。这些与建筑物安全相关的条件决定了进行专题分析时的业务过程，如混凝土坝的温控分析、土石坝的渗流场分析、不同土石坝结构型式的浸润线分析等。

大坝安全监测设计要求广泛收集工程条件资料，根据工程薄弱点及敏感区确定重点监测部位，充分考虑测点布设成线、成面的体系化，并与时间维度形成时空体系，即四维体系监测系统。由此，结合大坝安全监测中的通用名称，可以获得“建筑物”、“部位”、“监测线”、“监测断面”等关键知识，这些知识可以统称为“监测对象”，在监测对象的相应位置布置“测点”，测点的测值便可以代表大坝某位置的安全状态。同时，可以得到一个基本的层次关系：测点是最基本的领域对象，可以沿某条线布置形成监测线，如水管式沉降仪测点、测斜仪测点、静力水准仪测点、引张线仪测点、多点位移计测点等；它可以在某断面布置形成监测面，如混凝土某断面的所有温度测点、土石坝某横断面的所有渗压测点、大坝表面所有位移测点等；建筑物及其部位可以包含任意的测点、监测线、监测断面，是最大的集合。

如图2，将监测对象和测点分开作为两个重要的领域对象，确定了从属关系，有利于在监测对象的测点布置图上进行测点的导航、用颜色表示测点状态、显示测点最近测值及相关预警信息。

图2　监测对象及测点的领域模型Fig.2 Domain model of monitoring objects and monitoring points

监测基本的和最重要的目的是提供用于控制和显示各种不利情况下工程性能的评价和在施工期、运行初期和正常运行期对工程安全进行连续评估所需要的资料［5］。这些资料包括环境量（如降雨量、上游水位、下游水位、气温等）和效应量（如水平位移、垂直位移、应力、应变等）。由于原因量和效应量是随时间动态变化的，所以需要配备相应的专用设备进行长期性的监测。

测点设计用于监测某个物理量，就可以选择安装相应的仪器进行监测。而长期的监测，有时面临仪器更换或基准值变化的问题，这时，一个测点就可能有多种观测方式，且在不同的时段可能有不同的计算参数，这些都是需要应对的复杂性。所以，在大坝安全监测领域模型中引入“观测方案”、“观测项”和“仪器”对象，见图3。

观测方案属于相应的测点，而不采用“一个测点包含多个方案项”的方式，便于解耦多种观测方式带来的数据提取、显示等问题，比如一个测点既有人工观测方式，又有自动化观测方式，人工频次低，通常只用来比测，不用于报告的生成。

图3　观测方案及仪器的领域模型Fig.3 Domain model of observation scheme and monitoring in⁃struments

观测方案有多个方案项，若测点S所用仪器更换，就可以添加一个方案项，而不是重建一个S’来记录数据，实现了一个测点观测数据的连续性，为深度分析带来便利。若基准值或公式变化，也可以通过添加方案项来解决。同时，在方案项上可以扩展报警规则，对测点监测物理量在不同阶段设置相应的报警规则，如施工期、首次蓄水期、运行期等，满足不同阶段的限值要求。

仪器有物理量列表，包括直接观测的物理量（如频率、电阻比、电压）、中间计算物理量（如相对位移）、监测物理量（如位移、应力、应变、温度）。

2.3监测物理量分析

每种仪器会采集不同的物理量，通过计算得到所需的监测物理量。物理量的单位均作为知识存入知识库中备用。

对监测物理量进行分析可以得到的领域对象有“物理量”、“单位”，见图4。

对每种仪器设定了相应的单位，防止了局部修改造成单位的不一致问题。

2.4资料整编要求分析

大坝安全监测资料必须及时整理和整编，包括施工期、运行期的日常资料整理和定期资料整编。整理和整编的成果应做到项目齐全、数据可靠、资料、图表完整，规格统一。其中的“表”包括考证表、记录计算表、特征值统计表，“图”包括过程线图、相关性图、分布图、等值线图、统计模型成果图等。

图4　物理量及单位的领域模型Fig.4 Domain model of physical quantities and units

日常整理时需要快速浏览每个测点的过程线、查看相应的数据，所以单测点监测量表的输出和过程线的绘制是测点对象的业务。多点过程线图可以在单点图的样式上进行添加，以保证图表规格的统一。

相关性图用于分析测点监测量与环境量或其他测点监测量相关程度，也作为测点对象的业务。

分布图是为了分析某一时刻多个测点监测量在空间分布特征，这些测点通常呈线性布置，所以作为监测线的业务。

等值线图可以用于绘制某时刻一个投影平面上所有测点监测物理量的空间分布特征，可以作为监测面的业务。

整理和整编要求的表格可以在任何监测对象上输出，比如选择了测点对象，输出考证表，就是单测点的考证表，选择了监测线输出时，就是该监测线包含的所有测点的考证表，轻松实现了单测点、多测点表格输出业务的统一。

以过程线图为例，其领域模型可表示为图5，其他对象的领域模型不再赘述。

3　结语

以大坝安全监测设计作为监测信息系统的切入点，跟随设计工作，深入理解领域的关键知识，提取领域对象，然后，通过业务需求将领域对象关联起来，充分解耦其中的复杂关系，最终构建了一个单一的大坝安全监测领域模型，使开发人员和领域专家专注于这个统一模型上，实现了信息系统的各项功能。在工程实际应用中，该领域模型不仅能够方便地实现基本业务需求，而且对复杂业务也融合得恰到好处，相比数据为中心的开发模式，具有适应性强、测试时间短、维护难度低的特点。

图5　过程线图领域模型Fig.5 Domain model of the curve graph

参考文献：

［1］赵俐，盛海燕，刘霞.领域驱动设计——软件核心复杂性应对之道［M］.北京：人民邮电出版社，2010:43-45.

［2］Tim McCarthy.NET Domain-Driven Design with C#:Prob⁃lem-Design-Solution［M］.Wrox，2008:15-25.

［3］赵俐，马燕新.领域驱动设计与模式实战［M］.北京：人民邮电出版社，2009:10-12.

［4］王怀民，周斌.企业应用架构模式［M］.北京：机械工业出版社，2011:101-105.

［5］二滩水电开发有限公司.岩土工程安全监测手册［M］.北京：中国水利水电出版社，1999:7-8

［6］李英军，马晓星，蔡敏，等.设计模式——可复用面向对象软件的基础［M］.北京：机械工业出版社，2013:211-218.

作者邮箱：stanchion@sohu.com

Title:Dam safety monitoring information system based on domain driven design//by YI Guang-jun，HE Hu and SUN Jian-hui//Beijing IWHR Corporation

Abstract:In view of the limitations of traditional data-driven development model，domain driven design is proposed.By reasonable separation of the domain knowledge of dam safety monitoring，software devel⁃opers and dam safety monitoring experts can understand the unity of model expression of business logic. Moreover，the module coupling degree of dam safety monitoring information system is reduced，core busi⁃ness context is clear，which better adapts to demand changes and functional expansion.

Key words:dam safety monitoring；domain driven design；domain model

中图分类号：TP315

文献标志码：A

文章编号：1671-1092（2016）01-0037-05

收稿日期：2016-01-12

作者简介：易广军（1980-），男，陕西省泾阳县人，软件工程硕士，主要研究领域为工程安全监测软件系统设计与实现及水库安全鉴定评价。