DDD~概念中的DDD（转）

Posted 2020-08-08 三小

概念中的ＤＤＤ

ＤＤＤ：　领域驱动设计，它是对面向对象的的分析和设计（ＯＯＡＤ，Object Orient Analysis Design）的一个补充，对技术框架进行了分层规划，同时对每个类进行了策略和类型划分。领域模型是领域驱动的核心　，采用ＤＤＤ的设计思想，业务逻辑不再集中在几个大型的类上，而是在大量相对小的领域对象上，这些类具有自己的状态和行为，每个类都是完成的独立的，并与现实领域的业务对象形成一种映射。基于ＤＤＤ的架构设计，保证了系统的可维护性，扩展性和敏捷性，在处理复杂业务逻辑方面有着明显的优势！

编程世界观的改变

以下信息是从http://www.jdon.com/ddd.html上拷贝的，写的很好，这确实是一种编程世界观的改变，而传传统编程观念完全不同

过去需求分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。

　　DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。

　　DDD革命性在于：领域模型准确反映了业务语言，而传统的分层架构只关心数据， 这些数据对象除了简单读、写操作外，没有任何业务方法，被比喻成失血模型，那么领域模型这种带有业务方法的充血模型到底好在哪里？

看到领域模型代码，就看到业务需求，没有翻译没有转换，保证软件真正实现“拷贝不走样”。

DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。

ＤＤＤ的特点

• 分层架构

1. 成熟，清晰的分层架构
2. 领域对象与世界的业务映射
3. 明确的职责划分

• 复用性

1. 领域对象是核心
2. 领域对象复用：完整的业务对象描述
3. 设计利用：设计基于领域对象而非基于数据库的

• 适用场合

1. 具备复杂业务逻辑的软件开发
2. 对设计和开发人员要求较高
3. 不适合普通的ＣＵＲＤ操作
4. 系统的维护性与扩展性较高

对于ＤＤＤ系统架构的分层

不使用ＤＤＤ思想进行系统设计时，一般会分为３层，如数据层，业务层和表现层，而使用ＤＤＤ这后，分层的方式发生了一些改变，先来看一下

1. 表现层：也叫ＷＥＢ层，ＵＩ层，一般体现出来的是页面的布局，可以用web mvc,web form,win form等去实现
2. 应用层：用来协调应用活动，它不包含业务逻辑，它不保留业务对象的状态，但它保存应用任务的进度状态
3. 领域层：包含领域信息，这是业务软件的核心，它保留业务对象的状态，对业务对象和它们状态的持久化工作委托给基础设施层
4. 基础设施层：是其它层的基础，实现对业务对象的持久化，还对ＷＥＢ层可以引用本层

ＤＤＤ中的几个核心对象

Entities:这不是简单的poco实体，而是具备了业务逻辑的实体

Factories:工厂类，用来生产对象

Respositories:持久化,它本身就是DAO (Data Access Objects) 数据访问对象

Services：服务层，为上层提供了操作的接口，负责对象领域对象进行调试和封装，同时提供了各种形式的服务　　

 

ＯＫ，今天这讲先说到这里，只是概念，要求我们去理解它，事实上，这种理解确实有别于之前的架构思想，它是一种与传统方式截然不同的，需要我们用心去体会！

感谢您的阅读

 

相关文章

DDD~概念中的DDD

DDD~充血模型和失血模型

DDD~基础设施层

DDD~microsoft NLayerApp项目中的层次结构图

DDD~领域层

DDD~Unity在DDD中的使用

出处：http://www.cnblogs.com/lori/