DDD（领域驱动设计）

领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名：领域驱动设计—软件核心复杂性应对之道)一书。，书中提出了“领域驱动设计(简称 ddd)”的概念。

         领域驱动设计一般分为两个阶段：

   1.   以一种领域专家、设计人员、开发人员都能理解的“通用语言”作为相互交流的工具，在不断交流的过程中发现和挖出一些主要的领域概念，然后将这些概念设计成一个领域模型；

2.   由领域模型驱动软件设计，用代码来表现该领域模型。领域需求的最初细节，在功能层面通过领域专家的讨论得出。

 领域驱动设计告诉我们，在通过软件实现一个业务系统时，建立一个领域模型是非常重要和必要的，因为领域模型具有以下特点：

1.   领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反应了我们在领域内所关注的部分；

  2.   领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物，书本，应聘记录，地址，等；还能反映领域中的一些过程概念，如资金转账，等；

   4.   领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造；

     5.  领域模型贯穿软件分析、设计，以及开发的整个过程；领域专家、设计人员、开发人员通过领域模型进行交流，彼此共享知识与信息；因为大家面向的都是同一个模型，所以可以防止需求走样，可以让软件设计开发人员做出来的软件真正满足需求；

     6.  要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型；

     7.  为了让领域模型看的见，我们需要用一些方法来表示它；图是表达领域模型最常用的方式，但不是唯一的表达方式，代码或文字描述也能表达领域模型；

     8.  领域模型是整个软件的核心，是软件中最有价值和最具竞争力的部分；设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化；

领域驱动设计中的一些基本概念：

1．实体(entity)：

2．值对象(value object)

3．聚合及聚合根(aggregate、aggregate root)：

4．工厂(factories)：

5．仓储（repositories）：

6．服务（services）：

7．domain事件

8．DTO

  dto- datatransfer object（数据传输对象）：dto在设计之初的主要考量是以粗粒度的数据结构减少网络通信并简化调用接口。

领域驱动架构与n层架构设计

领域驱动架构

        eric  evans的“领域驱动设计- 应对软件的复杂性“一书中描述和解释了建议的n层架构高层次的图：

 

user interface：

        该层包含与其他系统/客户进行交互的接口与通信设施，在多数应用里，该层可能提供包括web services、rmi或rest等在内的一种或多种通信接口。该层主要由facade、dto和assembler三类组件构成，三类组件均是典型的j2ee模式。

        dto的作用最初主要是以粗粒度的数据结构减少网络通信并简化调用接口。在领域驱动设计中，采用dto模型，可以起到隐藏领域细节，帮助实现独立封闭的领域模型的作用。

        dto与领域对象之间的相互转换工作多由assembler承担，也有一些系统使用反射机制自动实现dto与领域对象之间的相互转换，如apache common beanutils。

        facade的用意在于为远程客户端提供粗粒度的调用接口。facade本身不处理任何的业务逻辑，它的主要工作就是将一个用户请求委派给一个或多个service进行处理，同时借助assembler将service传入或传出的领域对象转化为dto进行传输。

application：

         application层中主要组件就是service。这里需要注意的是，service的组织粒度和接口设计依据与传统transaction script风格的service是一致的，但是两者的实现却有质的区别。

　　transaction script(事务脚本)的核心是过程，通过过程的调用来组织业务逻辑，业务逻辑在服务（service）层进行处理。大部分业务应用都可以被看成一系列事务。

         transaction script的特点是简单容易理解，面向过程设计。  如果应用相对简单，在应用的生命周期里不会有基础设施技术的改变，尤其是业务逻辑很少会变动，采用transaction script风格简单自然，性能良好，容易理解。

        transaction script的缺点在于，对于复杂的业务逻辑难以保持良好的设计，事务之间的冗余代码不断增多。应用架构容易出现“胖服务层”和“贫血的领域模型”。同时，service层积聚越来越多的业务逻辑，导致可维护性和扩展性变差

　　领域模型属于面向对象设计，领域模型具备自己的属性行为和状态，领域对象元素之间通过聚合配合解决实际业务应用。可复用，可维护，易扩展，可以采用合适的设计模型进行详细设计。缺点是相对复杂，要求设计人员有良好的抽象能力。

        transactionscript风格业务逻辑主要在service中实现，而在领域驱动设计的架构里，service只负责协调并委派业务逻辑给领域对象进行处理。因此，我们可以考察这一点来识别系统是transaction script架构还是domain model架构。在实践中，设计良好的领域设计架构在开发过程中也容易向transaction script架构演变。

推荐阅读：

DDD（领域驱动设计）_王卫东的博客-CSDN博客_ddd领域