领域模型

最近几年， 领域驱动设计 （Domain-Driven Design， DDD ）这个术语越来越多地出现在软件工程师的视野里。对DDD不熟悉的人可能会觉得它是软件领域里的一个新的概念，但是实际上， Eric Evans 在十几年前就已经提出了这个概念。这个“古老”的概念在之所以能够重焕新生，很大程度上是因为遇上了“ 微服务 ”这个浪潮。如果把DDD里面的理念拿去和微服务架构做对比，你会发现它们有着高度的相似性——DDD里的 限界上下文 不正是微服务架构中的微服务吗？于是，各大公司纷纷运用DDD的方法论来构建自己的产品架构。有些团队成功地将DDD结合到了产品架构中，产生了许多优秀的实践；也有些团队反映DDD太过复杂，很难落地。那么DDD究竟是个什么样的理念？为什么大家都争先恐后地使用它，彷佛不加点DDD都不好意思说自己是微服务架构？然而又为什么那么多团队说DDD难以落地？本文将会结合简单的代码实现来谈谈笔者对DDD的理解。 什么是领域驱动设计？ 软件的核心是其为用户解决领域相关的问题的能力。 软件就是为了解决某一领域相关问题而存在的，比如一个普通的计算器软件，就是为了满足我们进行简单的加减乘除运算而存在。对于计算器这种小而简单的软件，一个普通的软件工程师可能花上几天就能过设计开发出来，而且基本不会出现Bug。但是对于一些大型而且复杂的系统，一个团队都得花上很长的时间去设计整个架构

注意，【】中是后来加的批注。因为随着对DDD的深入了解，对DTO的思考也有所改变。 分布式模式下，DTO层是一定需要的吗？ DTO 层的作用是为了隔离 Domain Model ：让 DoMain Model 的改动不会直接影响到 UI ；保持 Domain Model 的安全 , 不暴露业务逻辑。 【最大多数情况看来，UI或者DO的改动，都不可避免地会影响对方，即使中间有DTO隔离，所以这一个理由是不成立的。 至于安全问题，如果不是开放性平台（业务接口的调用者不是安全的），那么也没必要担心业务逻辑会暴露；即使是开放性平台，我们也可以用AOP做权限检查，限制第三者的非法调用。所以安全问题的理由也不成立。】 有两个方案可以省略 DTO 层，又能起到 DTO 的作用： l 继承：定义失血模型的 Model ，然后再做一个从 Model 继承的代理类 ，代理类里实现业务逻辑。贫血模型的 Model 单独为一个 DLL ，代理模型另起一个 DLL 。 Client 端只能引用贫血模型的 DLL ，这样就达到了隔离的目的，又省略了 Contract 层。 l 接口：为 Domain Model 做一个贫血模型的接口，接口单独为一个 DLL ， Client 端只引用接口 DLL 。 这两种方案的核心思想都是让数据字段与业务方法分离，然后只对 Client 端公开数据部份

原文地址：http://www.javaeye.com/topic/41745 没有一个项目不是重视需求调查的。从第一天开始，开发人员就拿着一个笔记本，把用户都拉到会议室，询问他们的业务流程是什么样的。知道了业务流程，开发者剩下的工作就明确了，一条一条的去实现他们，系统就OK了。但是，业务流程可以代替需求吗？ 实际上，在业务流程的背后，有一个更加根本的因素——商业需求。商业需求才是真正的需求，业务流程只是一种实现手段而已。 开发者询问用户：“你们的业务流程是什么样的？”这个问题其实是很难回答的。业务流程的制定首先是要最大限度的满足商业需求。并且，业务流程要受到 各种条件的制约，IT系统也是这个条件之一。开发者问用户业务流程是什么样的，用户也要问开发者系统的设计是什么样的，能达到什么样的性能指标，在这个基 础上才能制定合理的业务流程。 比如一家移动通信公司，在处理新用户入网的时候采用了一个这样的流程，按流程先后顺序： 1：首先把SIM卡和号码在交换网络上做对应关系的注册； 2：市场部把SIM卡存入一定的金额，发给销售商，收取销售商的货款； 3：销售商把卡卖给用户，用户填写入网合同，SIM装入手机可以立即通话； 4：销售商把入网合同交给市场部，市场部资料录入人员将用户的资料录入系统； 5：计费系统按照用户选择的资费对话单进行计费； 6、市场部按照用户的消费情况给销售商计算佣金和返利。

没有一个项目不是重视需求调查的。从第一天开始，开发人员就拿着一个笔记本，把用户都拉到会议室，询问他们的业务流程是什么样的。知道了业务流程，开发者剩下的工作就明确了，一条一条的去实现他们，系统就OK了。但是，业务流程可以代替需求吗？ 实际上，在业务流程的背后，有一个更加根本的因素——商业需求。商业需求才是真正的需求，业务流程只是一种实现手段而已。 开发者询问用户：“你们的业务流程是什么样的？”这个问题其实是很难回答的。业务流程的制定首先是要最大限度的满足商业需求。并且，业务流程要受到各种条件的制约，IT系统也是这个条件之一。开发者问用户业务流程是什么样的，用户也要问开发者系统的设计是什么样的，能达到什么样的性能指标，在这个基础上才能制定合理的业务流程。 比如一家移动通信公司，在处理新用户入网的时候采用了一个这样的流程，按流程先后顺序： 1：首先把SIM卡和号码在交换网络上做对应关系的注册； 2：市场部把SIM卡存入一定的金额，发给销售商，收取销售商的货款； 3：销售商把卡卖给用户，用户填写入网合同，SIM装入手机可以立即通话； 4：销售商把入网合同交给市场部，市场部资料录入人员将用户的资料录入系统； 5：计费系统按照用户选择的资费对话单进行计费； 6、市场部按照用户的消费情况给销售商计算佣金和返利。 这个流程的制定并不是业务部门可以单独确定的，他和IT系统有着很深的联系

1　　　　　 企业应用模式概述 　　1.1　　　 企业应用的模式 　　企业应用领域要解决的问题在某些方面要比做一个工具软件、或者一个电信通信软件等复杂的得多，比如纷杂的企业数据，各具特色的业务规则，变化莫测的用户需求。因此企业应用开发技术从CORBA、COM、J2EE、_NET等等，层出不穷，每一种技术的出现，都为企业问题的解决题供了一种思路，一个选择。 　　既然企业的问题是特定，那么我们就可以把问题进行分类，并把每一类问题的解决方法记录下来，这样，就形成了一套我们解决问题的思路，这就是模式。模式的核心就是特定的解决方案，它有效且有足够的通用性。借用一下Christopher Alexander给出的模式的定义：“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。 　　模式的关键点是它们来源于实践，他必须观察人们的工作过程，发现其中好的设计，并找出这些解决方案的核心，一旦发现了某个模式，那将是非常有价值的。当然，如果要学习一个模式，只是需要了解这些模式是干什么的、解决了那些问题、是如何解决问题的，就足够了。 　　 企业架构的领域问题有许多，如分层架构、Web表现、业务逻辑、数据库映射、并发、会话、分布策略、异步通信、安全、错误处理、集群、应用集成、架构重构。在此只选择了其中企业级应用程序的分层

应用服务和领域模型的边界在哪里？ 处理边界往往是一个比较棘手的问题。就像处理三八线一样，有的时候你会感觉对方的地盘属于你的，对方又感觉你的地盘属于他，然后要求重新重新划分。边界往往就是这样，经常出现冲突。 应用服务和领域模型的边界就没有像两个思想作怪那么复杂，因为他们具有规则和逻辑。所以只要弄懂什么是服务，什么是领域模型就可以解决这看似混乱的边界。 应用服务与领域模型的产生 应用服务和领域模型的出现是软件开发历史进程中的产物。在最开始的领域逻辑是混沌的，并没有领域模型，只是简单的事务脚本。在这个时期，一个脚本就对应一个业务用例。对于简单的业务来说这没什么问题，而且还很方便。但是当事务脚本中操作的模型对象超过两个以上，这时事务脚本就变得复杂起来，他完成了这些模型对象所有的业务逻辑。在这个时期事务脚本担任着全部的业务逻辑。随着业务复杂性的增加，人们解决问题域的抽象也变得更加接近现实。此时非过程化的面向对象编程也逐渐流行起来，所以也是时候将事务脚本的业务逻辑交给领域模型来解决了。从此事务脚本被一分为二，领域模型反应了细粒度业务逻辑，但是细粒度的领域模型在使用的过程又比较麻烦且繁琐，我们的业务流程常以粗粒度的用例模型来表达，所以我们需要一组类将细粒度的领域模型封装成粗粒度的用例模型供客户调用，这组封装的用例模型类叫做应用服务类。 应用服务包含什么内容？ 上面是从业务的角度分析应用服务的产生

最近一直在思考一个问题：有没有这样一种可能，就是一个领域模型的状态不依赖于外部，它只负责接收外部的事件，然后根据这些事件做出响应；响应分两种： 根据模型当前的内存状态进行业务逻辑处理，然后产生事件，注意：这个过程不会改变模型当前的内存状态； 根据事件改变自己的状态； 另外，也是最重要的，领域模型不用关心自己所产生的事件到底怎么样了，比如不关心有没有持久化，不关心是否和别的事件有并发冲突。它只管根据自己当前的内存状态做上面这两点的响应； 如果这样的设想有可能，那领域模型就是真正的中央业务逻辑处理器了，和CPU很类似了。这样它才能真正快起来。 简单的说就是：事件->模型->事件 模型只管响应事件，然后响应处理，然后产生新的事件 领域模型就是一黑盒，它只能帮你处理业务逻辑，其他的什么处理结果它一概不关心；当然，领域模型肯定有它自己的状态，但这个状态是驻留在内存的，和领域模型是一体的。 我为什么会有这个想法是因为，我在想，为什么要让领域模型的处理逻辑依赖于它的处理结果是否被正确顺利持久化了？感觉这很荒唐。 既然领域模型有自己的内存状态空间，他的所有逻辑也应该只依赖于这个状态空间，不再依赖于其他任何外部的东西。 当然，以前我们设计的IRepository，实际背后都是直接从数据库取。这样的话，领域模型的状态空间就是数据库了。但是这样其实很不好，为什么不用内存作为领域模型的状态空间呢？

一般的web结构 　　在前后台分离的情况下，我们对前端一般会以WEB API的形式同过JSON交互来与前端进行交互。一般来讲，我们的数据模型会在controller层进行交互，进行数据的校验与处理，然后交给service层进行相应的逻辑处理。如果service需要与数据库的支持，则调用dao层来获取与存储数据。这样分层的好处是当我们的数据存储方式发生了变化，如我们的数据库从oracle变成了mysql，我们只要改一下dao层的配置，不会影响我们的业务代码，特别注意的是，如果service层在调用不同的表时，我们最好调用对应表的service层的方法，不应该出现一个service调用多个dao的情况。 　　2. 分层领域模型 在阿里巴巴编码规约中列举了下面几个领域模型规约: DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。 DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。 BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。 AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。 VO（View Object）：显示层对象

如果你对项目管理、系统架构有兴趣，请加微信订阅号“softjg”，加入这个PM、架构师的大家庭 业务逻辑层是专门处理软件业务需求的一层，处于数据库之上，服务层之下，完成一些列对Domain Object的CRUD，作为一组微服务提供给服务层来组织在暴露给表现层，如库存检查，用法合法性检查，订单创建。 业务逻辑层包含领域对象模型，领域实体，业务规则，验证规则，业务流程。1：领域对象模型为系统结构描述，包含实体功能描述，实体之间的关系。领域模型处于天生的复杂性:2：领域实体：业务层是一些操作业务对象（BO）的处理。业务对象包含数据和行为，是一个完整的业务对象。其不同于上节架构设计中服务层的简单理解提到的数据迁移对象（dto），对于dto存在数据的，不存在行为，dto是bo（ddd中又称do）的子集，负责与特定界面需求的扁平化实体，dto仅仅是一个数据载体，需要跨越应用程序边界，而业务对象则不会存在复制迁移，往往一个业务对象存在一个或者多个数据迁移对象。3:业务最大的逻辑就在处理一些列现实世界的规则，这也是软件中最容易变化的部分，这里通常会出现我们众多的if-else或者switch-case的地方。也这因为如果说以个人觉得在我们的项目最应该关系和分离需求的层次。4：验证规则：业务规则很大程度上也是对对象的数据验证，验证业务对象的当前数据状态

分层领域模型规约与 领域模型命名规约 一、分层领域模型规约 DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。 DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。 BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。 AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。 VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。 Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。 二、领域模型命名规约 1） 数据对象：xxxDO，xxx即为数据表名。 2） 数据传输对象：xxxDTO，xxx为业务领域相关的名称。 3） 展示对象：xxxVO，xxx一般为网页名称。 4） POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。 来源： https://www.cnblogs.com/zfc-java/p/8215473.html