c语言软件建模,软件设计：DDD领域建模基本流程

DDD最初源于1990年AndreasZeller编写的VSL结构化语言，后来经过一些程序员的努力，演化成今天的模样。

DDD的功能非常强大，可以调试用C\\C++、Ada、Fortran、Pascal、Modula-2和Modula-3编写的程序；可以超文本方式浏览源代码；能够进行断点设置、回溯调试和历史纪录编辑；具有程序在终端运行的仿真窗口，并在远程主机上进行调试的能力；图形数据显示功能(GraphicalDataDisplay)是创建该调试器的初衷之一，能够显示各种数据结构之间的关系，并由此将数据结构以图形化形式显示；具有GDB/DBX/XDB的命令行界面，包括完全的文本编辑、历史纪录、搜寻引擎。

整理一个精简的DDD领域建模基本流程，供大家在DDD领域建模实践中进行参考。

1搜集用户故事(用户的原始需求)

2整理用户故事，抽出用例(用例表达了用户对系统的需求，定义了系统的边界以及系统外部角色和系统的交互场景)

3分析系统需求，将领域拆分为多个子域(领域是问题空间，本质上就是大问题拆分为小问题)

4抽取每个子域的领域概念，得到概念模型(概念模型存在于问题空间)

5将子域的概念模型抽象并转化为领域模型(领域模型存在于解决方案空间，这一步是难点，考验抽象能力，如对关系的建模，如促销系统中抽象出促销产品，权限系统中抽象出授权)

6找出领域模型中的聚合，以及每个聚合的聚合根

7梳理聚合之间的关系

8场景走查，检查领域模型如何满足用例需求

在以上过程中，还有两点也是非常重要的：

1逐步积累一个统一语言(UL)的领域术语表，方便各方人员沟通；

2除了领域建模外，针对每个用例场景，尝试画一下系统顺序图也很有用，系统顺序图定义了系统外部角色和系统之间在某个场景下的具体交互流程；

GNU DDD(Data Display Debugger)是命令行调试程序，如GDB、DBX、WDB、Ladebug、JDB、XDB、PerlDebugger或PythonDebugger的可视化图形前端。它特有的图形数据显示功能(GraphicalDataDisplay)可以把数据结构按照图形的方式显示出来。

领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

业务对象模型(也叫领域模型domainmodel)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。

该模型为产生预期效果确定了业务人员以及他们处理和使用的对象("业务类和对象")之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。

在业务对象模型中，业务角色代表雇员将担当的角色，而业务实体则代表雇员将处理的对象。一方面，可以使用业务对象模型来确定业务雇员将如何进行交互，以产生业务主角所期望的结果。另一方面，系统用例模型和设计模型指定了业务的信息系统。

业务建模和系统建模解决不同的问题，其抽象程度也不一样。所以一般而言，信息系统不应该直接出现在业务模型中。