领域驱动设计

我们都知道，很多业务系统都是基于 MVC 三层架构来开发的。实际上，更确切点讲，这是一种基于贫血模型的 MVC 三层架构开发模式。 虽然这种开发模式已经成为标准的 Web 项目的开发模式，但它却违反了面向对象编程风格，是一种彻彻底底的面向过程的编程风格，因此而被有些人称为反模式（ anti-pattern ）。特别是 领域驱动设计 （ Domain Driven Design ，简称 DDD ）盛行之后，这种基于贫血模型的传统的开发模式就更加被人诟病。而基于充血模型的 DDD 开发模式越来越被人提倡。 基于上面的描述，我们先搞清楚下面几个问题： 什么是贫血模型？什么是充血模型？ 为什么说基于贫血模型的传统开发模式违反 OOP ? 基于贫血模型的传统开发模式既然违反 OOP ，那又为什么如此流行？ 什么情况下我们应该考虑使用基于充血模型的 DDD 开发模式？ 什么是基于贫血模型的传统开发模式？ 对于大部分的后端开发工程师来说， MVC 三层架构都不会陌生。 MVC 三层架构中的 M 表示 Model ， V 表示 View ， C 表示 Controller 。它将整个项目分为三层：展示层、逻辑层、数据层。 MVC 三层开发架构是一个比较笼统的分层方式，落实到具体的开发层面，很多项目也并不会 100% 遵从 MVC 固定的分层方式，而是会根据具体的项目需求，做适当的调整。 比如

作者：邹溪源，长沙资深互联网从业者，架构师社区合伙人！ 一 犹记得刚刚参加工作时，是地图厂商四维图新集团旗下的一家子公司，主要从事规划测绘相关软件研发的公司。当时我的项目是为勘测设计院提供相对应的应用软件，对地理信息和规划相关的图纸信息领域的认知，几乎已经专业水平。事实上，规划设计大概和软件设计类似，有规划的设计、或无规划的设计，造成的结果几乎是天壤之别。 我们或许很容易就能设想到一个毫无规划设计的城市，纵横交错的路网、杂乱无章式的建筑布局、各种凌乱的棚户区设计，恰好象征着软件设计的无序性，也恰好体现了软件企业在经费不足、组织缺乏管理、开发者能力不足、软件随时随地想改就改时的行业现状，只能说这样的软件是最能符合当时实际劳动生产力水平的产品。 图一：巴西棚户区如图一所示，巴西棚户区，层层叠叠、风格迥异、密密麻麻，如果作为一个外人贸然来到这样的地方，大概很容易迷失期间、更不用说充斥在棚户区的各类毒品和黑社会。杂乱无章的建筑和街区，就像代码中错综复杂的调用链；而借助贫民区搞事的黑社会就像是代码中的异味或者bug，表面上看起来如此平静、与世无争、但是你永远也不知道啥时候会来一冷枪。 不要以为离我们很远，我们其实轻易就能写出这样的软件工程项目。不一定是“大泥球”系统，也有可能只是一些看似简单的业务系统，但内部代码逻辑，可能会复杂到令人窒息的程度

点击上方“马蜂窝技术”，关注订阅更多优质内容 前言 正如领域驱动设计之父 Eric Evans 所著一书的书名所述，领域驱动设计（Domain Driven Design）是一种软件核心复杂性应对之道。 在我们解决现实业务问题时，会面对非常复杂的业务逻辑。即使是同一个事物，在多个子业务单元下代表的意思也是不完全一样的。比如「商品」这个词，在商品详情页语境中，是指「商品基本信息」；在下单页语境中，是指「购买项」；而在物流页面语境中，又变成了「被运送的货物」。 DDD 的核心思想就是让正确的领域模型发挥作用。所谓「术业有专攻」，DDD 指导软件开发人员将不同的子业务单元划分为不同的子领域，在各个子领域内部分别对事物进行建模，来应对业务的复杂性。 Part 1 重构优惠中心的背景 我们在实际的开发过程中都遇到过这种情况，最初因为业务逻辑比较单一，为了快速实现功能， 以及对成本、风险等因素的综合考虑，我们会为业务统一创建一个大的模型，各个模块都使用这同一个模型。但随着业务的发展，各子领域的逻辑越来越复杂，对这个大模型的修改就会变成一种灾难，有时明明是要改一个 A 子领域的逻辑，却莫名其妙影响到了 B 或者 C 子领域的线上功能。 优惠中心就是一个例子。优惠中心主要负责马蜂窝各业务线商品的优惠活动管理，以及计算不同用户的优惠结果。 「 商品管理 」 和 「 优惠管理 」

什么是领域驱动设计 领域驱动设计是Eric Evans 定义的一种发展理念， 软件中的复杂性：包含“某种程度上确实有用但无法解释如何运行但代码”。软件变得复杂及难以管理但一个主要原因在于，领域复杂性和技术复杂性混合在来一起。 复杂问题域产生的原因（泥球模式） 软件复杂性：偶发性技术复杂性和领域逻辑复杂性。 1.未使用通用语言创建的代码：对于公共语言和问题域知识缺乏重视会导致代码库可用但无法揭示业务目的，这会使得代码库难以阅读和维护，因为分析模型与代码模型之间的转译将会代价高昂且容易出错。备注：分析模型：分析模型用于描述一个软件应用程序的逻辑设计与结构。它可以由示意图或使用UML这样的建模语言来表示。它是软件的一种表现形式，让非技术人员能够概念化以便理解软件是如何构造的。 2.组织结构的缺乏：一个系统的最初体现是快速制作且通常能获得面面俱到的成功，但由于缺乏基于围绕问题域模型的应用程序设计的重视，后续的功能扩展就会变得很棘手。 泥球模式的危害 1.泥球模式将扼杀开发：开发团队会不断抱怨在如此一团混乱的情况下难以开展工作。开发速度的增长水平也无法满足业务需求。 2.缺乏对问题域的关注：当不能充分理解正在处理的业务领域时，软件项目就会失败。编码不应该是困难的哪一环，维持一个能够满足业务用例的有用软件模型才是难点所在。 什么是问题域 问题域涉及你当前正在构建软件的主题领域

我们都知道，很多业务系统都是基于 MVC 三层架构来开发的。实际上，更确切点讲，这是一种基于贫血模型的 MVC 三层架构开发模式。 虽然这种开发模式已经成为标准的 Web 项目的开发模式，但它却违反了面向对象编程风格，是一种彻彻底底的面向过程的编程风格，因此而被有些人称为反模式（ anti-pattern ）。特别是 领域驱动设计 （ Domain Driven Design ，简称 DDD ）盛行之后，这种基于贫血模型的传统的开发模式就更加被人诟病。而基于充血模型的 DDD 开发模式越来越被人提倡。 基于上面的描述，我们先搞清楚下面几个问题： 什么是贫血模型？什么是充血模型？ 为什么说基于贫血模型的传统开发模式违反 OOP ? 基于贫血模型的传统开发模式既然违反 OOP ，那又为什么如此流行？ 什么情况下我们应该考虑使用基于充血模型的 DDD 开发模式？ 什么是基于贫血模型的传统开发模式？ 对于大部分的后端开发工程师来说， MVC 三层架构都不会陌生。 MVC 三层架构中的 M 表示 Model ， V 表示 View ， C 表示 Controller 。它将整个项目分为三层：展示层、逻辑层、数据层。 MVC 三层开发架构是一个比较笼统的分层方式，落实到具体的开发层面，很多项目也并不会 100% 遵从 MVC 固定的分层方式，而是会根据具体的项目需求，做适当的调整。 比如

1. DDD 领域驱动设计 首先是支撑微服务设计思想的DDD，这套理论讲述了如何划分微服务的子系统。 识别domain，领域模型 识别业务边界 画出UML图，结合领域专家共同进行领域建模，随着时间演进 领域驱动设计的实质 ：消化知识 建立领域模型 Tip 业务规则单独抽一层出来 利用策略模式 使业务规则更好阅读 from 领域驱动设计：软件核心复杂性对应之道 2.ADD 属性驱动设计 3.TDD 测试驱动开发 来源： https://my.oschina.net/xlpapapa/blog/3101095

领域驱动设计系列（2）浅析VO、DTO、DO、PO的概念、区别和用处 作者: Johnny.Liang 发布时间: 2015-06-02 18:47 阅读: 5612 次 推荐: 13 原文链接 [收藏] 　　 上一篇 文章作为一个引子，说明了领域驱动设计的优势，从本篇文章开始，笔者将会结合自己的实际经验，谈及领域驱动设计的应用。本篇文章主要讨论一下我们经常会用到的一些对象：VO、DTO、DO和PO。 　　由于不同的项目和开发人员有不同的命名习惯，这里我首先对上述的概念进行一个简单描述，名字只是个标识，我们重点关注其概念： 　　 概念： 　　VO （View Object ）： 视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。 　　DTO （Data Transfer Object ）： 数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。 　　DO （Domain Object ）： 领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。 　　PO （Persistent Object ）： 持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系