领域模型

原文: 领域驱动设计学习之路―DDD的原则与实践 本文是我学习Scott Millett & Nick Tune编著的《领域驱动设计模式、原理与实践》一书的学习笔记，一共会分为4个部分如下，此文为第1部分： ① 领域驱动设计的原则与实践 ② 战略模式：在有界上下文之间通信 ③ 战术模式：创建有效的领域模型 一、什么是领域驱动设计 　　脑图浏览： https://www.processon.com/view/5cb49b14e4b0a13c9de1042d#map 　　这一章主要介绍了DDD是什么，强调DDD是一种开发思想体系， 它是模式（战略模式、战术模式）、原则和实践的集合 ，可以被应用到软件设计中以 管理复杂性 。 　　DDD并非一种模式语言，它是专注于交付的一种协作思想体系，其中 通信起核心作用 ，而要高效通信，就需要使用公共语言。 　　DDD会将侧重点放在以下几个方面： 核心领域 协作 与领域专家探讨 实验研究以生成更有用的模型 对各种上下文的理解 　　更为重要的是，不要认为DDD是一套框架，DDD也不是银弹或灵丹妙药，不可在项目中小题大做！ 　　下图展示了一个演进的领域驱动设计过程： From：张逸《领域驱动战略设计实践》课程 　　这里摘抄一段张逸老师在《领域驱动战略设计实践》课程中的话： 　　面对客户的业务需求，由领域专家与开发团队展开充分的交流，经过需求分析与知识提炼

什么是领域驱动设计 领域驱动设计（DDD） ：DDD的全称为Domain-driven Design，是一套综合软件系统分析和设计的面向对象建模方法，是针对复杂系统设计的一套软件工程方法，是一种思想。 什么是领域：领域是问题域 + 业务期望 一：问题域：领域中有许多的问题域,领域是有边界的，要注重核心要解决的问题，问题域建模的过程就是业务领域分析的过程 二：业务期望：确定业务的期望与愿景，业务的范围，识别出业务需求的价值，识别出最核心的业务 什么是驱动： 一：领域驱动领域模型设计，需求分析 =>领域模型 ，领域模型驱动代码实现，领域模型 =>代码实现 ，分析领域中的核心问题（核心关注点），然后设计对应的领域模型，再通过领域模型驱动代码实现。 什么是设计： 一：DDD中的设计主要指领域模型的设计，DDD是一种基于模型驱动开发的软件开发思想，强调领域模型是整个系统的核心，领域模型也是整个系统的核心价值所在 二：领域的设计分为2阶段： 1.领域驱动领域模型设计，需求分析 =>领域模型 =>战略设计，根据业务设计领域模型，领域模型是整个系统的核心，领域模型要反映业务需求 2.领域模型驱动代码实现，领域模型 =>代码实现 =>战术设计，代码实现要严格按照领域模型的意图来落地 为什么要使用领域驱动设计 一：不同于传统以数据表为中心的建模方式，它以业务领域为中心来建模，迭代过程中

一、简介 领域驱动设计顾名思义是一种设计思想，由领域来驱动设计的进行。这里的领域可以简单理解为我们常说的“业务”。也即是，由对业务的深入分析来驱动软件设计工作。 领域驱动设计从层次上分为战略设计和战术设计，我们可以这么想，战略设计就是从上层进行抽象性设计，而战术设计就是将这些上层抽象作为下层具体实现进行的设计工作。 本文涉及的领域、子域、限界上下文就是属于战略设计。 二、概念 什么是领域？ 我们可以把领域当作一个大的问题域来理解，如果对一个企业来说，那么就是这个企业要做的所有事情。 什么是子域？ 子域是相对于领域的一个概念，顾名思义就是领域被细化以后分成了不同的子域。这个应该相对比较好理解，因为我们人习惯性的会将大的东西进行分割，然后逐个击破。比如“分层思想”，“模块化思想”等。 那么子域就是将一个大的问题域拆分成了很多小的问题域。 并且根据子域的重要性以及作用范围将子域分成了： 1、核心域：重要性最强 2、支撑子域：重要性较低，辅助核心域 3、通用子域：给所有域提供辅助 什么是限界上下文？ 开发软件的目的就是为了解决问题，领域定义了问题域，子域细分了问题域。那么我们需要考虑如何根据这些问题域来设计解决方案。 我们说的解决方案就是“领域模型”，领域驱动设计即根据问题域来进行建模。 可是我们想一下，如果我们对整个领域建立一个模型是不是太可怕了，如果系统过于庞大

说起应用分层，大部分人都会认为这个不是很简单嘛 就 Controller ， Service , Mapper 三层。看起来简单，很多人其实并没有把他们职责划分开，在很多代码中, Controller 做的逻辑比 Service 还多, Service 往往当成透传了，这其实是很多人开发代码都没有注意到的地方，反正功能也能用，至于放哪无所谓呗。这样往往造成后面代码无法复用，层级关系混乱，对后续代码的维护非常麻烦。 一个好的应用分层需要具备以下几点: 方便后续代码进行维护扩展； 分层的效果需要让整个团队都接受； 各个层职责边界清晰。 在阿里的编码规范中约束的分层如下: 开放接口层：可直接封装 Service 方法暴露成 RPC 接口;通过 Web 封装成 http 接口;进行 网关安全控制、流量控制等。 终端显示层：各个端的模板渲染并执行显示的层。 Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。 Service 层：相对具体的业务逻辑服务层。 Manager 层：通用业务处理层，它有如下特征: 对第三方平台封装的层，预处理返回结果及转化异常信息; 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理; 与 DAO 层交互，对多个 DAO 的组合复用。 DAO 层：数据访问层，与底层 MySQL 、 Oracle 、

原文地址： https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html 领域驱动设计之领域模型 加一个导航，关于如何设计聚合的详细思考，见 这篇 文章。 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计），简称Evans DDD。领域驱动设计分为两个阶段： 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型； 由领域模型驱动软件设计，用代码来实现该领域模型； 由此可见，领域驱动设计的核心是建立正确的领域模型。 为什么建立一个领域模型是重要的 领域驱动设计告诉我们，在通过软件实现一个业务系统时，建立一个领域模型是非常重要和必要的，因为领域模型具有以下特点： 领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反应了我们在领域内所关注的部分； 领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物，书本，应聘记录，地址，等；还能反映领域中的一些过程概念，如资金转账，等； 领域模型确保了我们的软件的业务逻辑都在一个模型中

Martin Fowler在《 企业应用架构模式 》一书中写道： I found this(business logic) a curious term because there are few things that are less logical than business logic. 初略翻译过来可以理解为：业务逻辑是很没有逻辑的逻辑。 的确，很多时候软件的业务逻辑是无法通过推理而得到的，有时甚至是被臆想出来的。这样的结果使得原本已经很复杂的业务变得更加复杂而难以理解。而在具体编码实现时，除了应付业务上的复杂性，技术上的复杂性也不能忽略，比如我们要讲究技术上的分层，要遵循软件开发的基本原则，又比如要考虑到性能和安全等等。 在很多项目中，技术复杂度与业务复杂度相互交错纠缠不清，这种火上浇油的做法成为不少软件项目无法继续往下演进的原因。然而，在合理的设计下，技术和业务是可以分离开来或者至少它们之间的耦合度是可以降低的。在不同的软件建模方法中， 领域驱动设计 (Domain Driven Design,DDD)尝试通过其自有的原则与套路来解决软件的复杂性问题，它将研发者的目光首先聚焦在业务本身上，使技术架构和代码实现成为软件建模过程中的“副产品”。 DDD总览 DDD分为战略设计和战术设计。在战略设计中，我们讲求的是子域和 限界上下文(Bounded Context,BC)

1、引言 Module，即模块，是指提供特定功能的相对独立的单元。提到模块，你肯定就会想到模块化设计思想，也就是功能的分解和组合。对于简单问题，可以直接构建单一模块的程序。而对于复杂问题，则可以先创建若干个较小的模块，然后将它们组装、链接在一起，从而构成复杂的软件系统。 在DDD中，模块的用途也是如此，通过分解领域模型为不同的模块，以降低领域模型的复杂性，提高领域模型的可读性。 二、DDD中的模块 模块是一个笼统的概念，比较宽泛，为了正确发挥模块的威力，理解模块的概念就十分重要。下面我们从具体的问题着手，来尝试说明模块的概念。 就拿电商系统来说，维护一个订单，需要收货地址、购买商品、订单信息。这些信息是紧密相关的，不可独立存在。我们可以抽象出三个简单的聚合。那这些类该如何存放呢？是为每一个聚合创建一个文件夹存放还是放在同一个文件夹？我想答案不言而喻。 这三个聚合就是一个模块，一个客户模块。通过定义一个order文件夹，来将相关联的领域对象组合起来。 通过以上的举例说明，我们可以看到每个模块都是相对独立的功能单元。通过模块来组织和封装相关概念，来分解领域模型，以简化领域模型的复杂性。 但不要将模块与子域和限界上下文混淆。在复杂的领域模型中，为了对领域模型中进行准确建模，需要将领域模型拆分成多个子域，每个子域对应一个或多个限界上下文。在限界上下文中

1、引言 Module，即模块，是指提供特定功能的相对独立的单元。提到模块，你肯定就会想到模块化设计思想，也就是功能的分解和组合。对于简单问题，可以直接构建单一模块的程序。而对于复杂问题，则可以先创建若干个较小的模块，然后将它们组装、链接在一起，从而构成复杂的软件系统。 在DDD中，模块的用途也是如此，通过分解领域模型为不同的模块，以降低领域模型的复杂性，提高领域模型的可读性。 二、DDD中的模块 模块是一个笼统的概念，比较宽泛，为了正确发挥模块的威力，理解模块的概念就十分重要。下面我们从具体的问题着手，来尝试说明模块的概念。 就拿电商系统来说，维护一个订单，需要收货地址、购买商品、订单信息。这些信息是紧密相关的，不可独立存在。我们可以抽象出三个简单的聚合。那这些类该如何存放呢？是为每一个聚合创建一个文件夹存放还是放在同一个文件夹？我想答案不言而喻。 这三个聚合就是一个模块，一个客户模块。通过定义一个order文件夹，来将相关联的领域对象组合起来。 通过以上的举例说明，我们可以看到每个模块都是相对独立的功能单元。通过模块来组织和封装相关概念，来分解领域模型，以简化领域模型的复杂性。 但不要将模块与子域和限界上下文混淆。在复杂的领域模型中，为了对领域模型中进行准确建模，需要将领域模型拆分成多个子域，每个子域对应一个或多个限界上下文。在限界上下文中

失血模型： 失血模型简单来说，就是domain object只有属性的getter/setter方法的纯数据类，所有的业务逻辑完全由business object来完成(又称TransactionScript)，这种模型下的domain object被Martin Fowler称之为“贫血的domain object”。 所以在Java里面，类中的所有属性都由private来修饰，且只有属性的getter/setter方法来访问属性。 以后学习待更新...... 来源： https://www.cnblogs.com/dajingshao/p/11568058.html

2.1 知识提炼与协作 知识提炼是从问题域中提炼出相关信息的技术，其目的是构建能够满足业务用例需求的有用模型。 知识提炼是为技术团队在基于一组需求为问题域设计解决方案时弥补所欠缺的知识的关键技术。 知识提炼--对问题深刻理解的人--大家的共同协作。 知识收集过程会出现在与业务专家探讨示例时的白板上，且通常会同时展开头脑风暴。 问题域 == 业务用例 ==有用的模型 == 知识提炼。具体操作一波。 2.1.1 通过通用语言达成共识 通用语言（UL）显示制作，并在描述领域模型和问题域使用，该语言还应用于模型的代码实现，使用用作类名称，属性和方法名称的相同的术语和概念。 2.1.2 领域知识的重要性 领域知识 == 业务知识 技术知识 从业务到技术的翻译是开发人员需要具备的。 2.1.3 业务分析员的角色 不要将开发团队和最理解该部分业务的人之间的沟通完全屏蔽。 2.1.4 一个持续过程 模型驱动设计和领域模型的演化是一个持续过程。知识提炼在整个应用程序构建的生命周期中应该在业务参与的情况下被持续关注。 认识到随着系统的每一次迭代，模型都会有所演化，===模型永远不会尽善尽美，它只是对于当前问题可用而以。 2.2 与领域专家一起获得领域见解 2.2.1 领域专家和业务相关人员的对比 问题空间会给出一组需求，输入和预期输出 ===业务相关人员提供的。 解空间包含一个能满足需求需要的模型 =