DDD领域设计在“图生代码”中的应用实践

前言

领域驱动设计(简称 ddd)概念来源于2004年著名建模专家Eric Evans 发表的他最具影响力的书籍:《领域驱动设计——软件核心复杂性应对之道》（Domain-Driven Design –Tackling Complexity in the Heart of Software），简称Evans DDD。领域驱动设计思想进入软件开发者的视野。在将近20年的发展中领域模型设计一直占据着非常重要的位置。但由于其本身理论性较强，在应用过程中多数用来描述和解决复杂性问题。但本文的目的不在于介绍领域驱动设计，而是站在“图形代码一体化”的角度利用DDD模型实现代码的展示以及逻辑划分以及相应的规范设计。

添加图片注释，不超过 140 字（可选）

一，DDD理论在图生代码中的融合

（1）软件积木理论的两个特定条件

图生代码，其中的“图”其实更多的理解能够为更多非专业程序员能够认识并发现的“积木”模块，而设计软件就像拼积木一样，只要遵循图示给出的拼搭过程，不经思考就能拼出期待的模型。但实践证明要完美的想实现这一过程，还需要两个必备的条件。1，特别定制的积木 2，在特定的场景下。

添加图片注释，不超过 140 字（可选）

（2）特别定制：由“图”反推定制代码

为特定的业务做专业的分解，再注入一些基础的模型理论以及可视化的特性，这些是常用软件“积木”通用方法论，这些特别定制最终再落到具有特定技术背景指定技术框架的技术实现“产品代码”。但“图生代码”是这一过程是逆向操作，从方法论上而言是先确定边界及需求再谋求技术路线。但从产品的角度而言则是移除产品功能边界从更高的层面上谋求战术与战略的商业述求。

添加图片注释，不超过 140 字（可选）

（3）特定场景：DDD规范中的战略与战术设计

在DDD中最不缺的就是概念，三个“D”中每一个都是一个厚重的理论基础。在软件产品中，每一个角色都能在其中找到所需要的述求。

添加图片注释，不超过 140 字（可选）

二，DDD领域设计实践——领域职责划分与配置

DDD在设计上是拥有非常严谨的逻辑划分以及分工职责的，是一门适合复杂应用的纲领性设计指导。其复杂度和实施难度是非常大的，但如何做出来一个实践一个优秀DDD应用，并不是本文的重点，本文更多的是探讨如何将DDD的一些应用分析方法应用到“图生代码”这个特定的课题下。让“生成代码”拥有更好的领域特性绑定领域模型融合。