领域驱动设计和实践

很薄的一层，用来协调应用的运动。它不包罗营业逻辑。它不保留营业工具的状态，但它保有应用使命的进度状态。

领域层 

本层包罗关于领域的信息。这是营业软件的焦点所在。在这里保留营业工具的状态，对营业工具和它们状态的持久化被委托给了基础设施层。

基础设施层 

本层作为其他层的支持库存在。它提供了层间的通讯，实现对营业工具的持久化，包罗对用户界面层的支持库等作用。

　　领域驱动设计除了对系统架构举行了分层形貌，还对工具（Object）做了明确的职责和计谋划分：

实体（Entities）：具备唯一ID，能够被持久化，具备营业逻辑，对应现实天下营业工具。值工具（Value objects）：不具有唯一ID，由工具的属性形貌，一样平常为内存中的暂时工具，可以用来通报参数或对实体举行增补形貌。工厂（Factories）：主要用来建立实体，现在架构实践中一样平常接纳IOC容器来实现工厂的功效。堆栈（Repositories）：用来治理实体的荟萃，封装持久化框架。服务（Services）：为上层修建提供可操作的接口，卖力对领域工具举行调理和封装，同时可以对外提供种种形式的服务。

　　固然，DDD中还提出了聚合和聚合根（Aggregate Root）的观点，不外我们在实践历程发现聚合根有问题庞大化的倾向，用传统的聚合、组合等观点去形貌领域工具之间的关系更容易明白，以是这里对这个观点就不做先容了。

　　Martin Fowler 2004年所著的企业应用架构模式（Patterns of Enterprise Application Architecture）中的第九章领域逻辑模式（Domain Logic Patterns）专门先容了事务剧本（Transaction Script）和领域模子（Domain Model），明白这两种模式对设计和构建企业应用软件很是有资助，以是有须要先容一下。

　　事务剧本：

　　事务剧本的焦点是历程，通过历程的挪用来组织营业逻辑，每个历程处置惩罚来自体现层的单个请求。大部门营业应用都可以被看成一系列事务，从某种水平上来说，通过事务剧本处置惩罚营业，就像执行一条条SQL语句来实现数据库信息的处置惩罚。事务剧本把营业逻辑组织成单个历程，在历程中直接挪用数据库，营业逻辑在服务（Service）层处置惩罚。

　　事务剧本模式可以简朴的通过UML图表现成这样：

　　由Action层处置惩罚UI层的行动请求，将Request中的数据组装后通报给BusinessService，BS层做简朴的逻辑处置惩罚后，挪用数据会见工具举行数据持久化，其中VO充当了数据传输工具的作用，一样平常是血虚的POJO，只具备getter和setter要领，没有状态和行为。

　　事务剧本模式的特点是简朴容易明白，面向历程设计。对于少量逻辑的营业应用来说，事务剧本模式简朴自然，性能优秀，容易明白，而且一个事务的处置惩罚不会影响其他事务。不外弱点也很显着，对于庞大的营业逻辑处置惩罚力有未逮，难以保持优秀的设计，事务之间的冗余代码不停增多，通过复制粘贴方式举行复用。可维护性和扩展性变差。

　　领域模子：

　　领域模子的特点也比力显着， 属于面向工具设计，领域模子具备自己的属性行为状态，并与现实天下的营业工具相映射。各种具备明确的职责划分，领域工具元素之间通过聚合和引用等关系配合解决现实营业应用和规则。可复用，可维护，易扩展，可以接纳合适的设计模子举行详细设计。弱点是相对庞大，要求设计职员有优秀的抽象能力。

　　领域模子对应的就是领域驱动设计中划分的领域层，这里就不详细讨论了。

　　在现实的设计中，我们需要凭据详细的需求选择响应的设计模式。具备庞大营业逻辑的焦点营业系统适合使用领域模子，简朴的信息治理系统可以思量接纳事务剧本模式。

　　下面主要讲一下我们在构建企业级应用开发平台中对DDD的实践和扩展。

　　本人近年来一直在从事企业级应用开发平台的相关事情，GAP平台是我们的一个软件产物，用来解决企业级软件开发历程中复用、快速开发和历程规范等问题。设计这样一个平台，从底层的框架上就应该能够支持庞大营业逻辑的系统构建，以是我们在大的架构设计思绪上接纳了领域驱动设计的思绪，并凭据现实接纳的手艺和要实现的功效对DDD的四层架构举行了细化和实现：

 2/4   首页 上一页 1 2 3 4 下一页 尾页