《领域驱动设计》基础知识汇总.docxVIP

领域驱动设计》基础知识汇总（转） 1. 什么是领域（ Domain ） 我们所做的软件系统的目的都是来解决一系列问题，例如做一个电商系统来在线销售自己 企业的产品；做一个灰度发布平台来提升服务的质量和稳定性。任何一个系统都会属于某 个特定的领域，例如： ? 论坛是一个领域：要做一个论坛，那这个论坛的核心业务是确定的：比如用户发帖、回 帖等核心基本功能； ? 电商系统是一个领域：只要是电商领域的系统，那核心业务就是：商品浏览、购物车、 下单、减库存、付款交易等核心环节； 同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。因此 可以推断：一个领域本质上可以理解为一个问题域 。只要确定了系统所属的领域，那么这 个系统的核心业务，即要解决的关键问题就基本确定了。通常我们说，要成为一个领域的 专家，必须要在这个领域深入研究很多年才行，只有这样才会遇到非常多的该领域的问题， 积累了丰富的经验。 2.界限上下文（ Bounded Context） 通常来说，一个领域有且只有一个核心问题，我们称之为该领域的『核心子域』 。在核心 子域、通用子域、支撑子域梳理的同时，会定义出子域中的『限界上下文』及其关系，用 它来 阐述子域之间的关系 。界限上下文可以简单理解成一个子系统或组件模块。 例如：下图是对酒店管理的子域和界限上下文的梳理： 3. 领域模型( Domain Model ) 领域驱动设计( Domain-Driven Design )分为两个阶段： 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交 流的过程中发现领域概念，然后将这些概念设计成一个领域模型； 由领域模型驱动软件设计，用代码来实现该领域模型； 由此可见，领域驱动设计的核心是建立正确的领域模型。领域模型具有 以下特点 ： 对具有某个边界的领域的一个 抽象 ，反映了领域内用户 业务需求的本质 。它属于『解 决问题空间』。领域模型是有边界的，只反应了我们在领域内所关注的部分，包括 实体概 念(如：货物，书本，应聘记录，地址等) ，以及 过程概念 (如：资金转账等) ； 提高软件的 可维护性 ，业务可理解性 以及 可重用性 。领域模型确保了我们的软件的业 务逻辑都在一个模型中，帮助开发人员相对平滑地将领域知识转化为软件构造； 贯穿软件 分析、设计、开发 的整个过程。领域专家、设计人员、开发人员面向同一个 模型进行交流，彼此共享知识与信息，所以可以防止需求走样，让软件开发人员做出来的 软件真正满足需求；要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积 极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型； 为了让领域模型看的见，使用的常用表达领域模型的方式：图、代码或文字； 重要性：领域模型是整个软件的核心，是软件中最有价值和最具竞争力的部分；设计足 够精良且符合业务需求的领域模型能够更快速的响应需求变化； 领域通用语言 由软件专家和领域专家合作开发一个领域的模型是有必要的。开发过程中， 开发人员以类、 算法、设计模式、架构等进行思考与交流。但领域专家对此一无所知，他们对技术上的术 语没有太多概念，只了解特有的领域专业技能，例如：在空中交通监控样例中，领域专家 知道飞机、路线、海拔、经度、纬度，他们有自己的术语来讨论这些事情。软件专家和领 域专家交流过程中，需要做翻译才能让对方理解这些概念。 领域驱动设计的一个核心原则是使用一种基于模型的语言。使用模型作为语言的核心骨架， 要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样，这种语言被称为 『通用语言』 建模思考的问题：用户需求 『用户需求』不能等同于『用户』 ，捕捉『用户心中的模型』也不能等同于『以用户为核 心设计领域模型』 。设计领域模型时不能以用户为出发点去思考问题，不能老想着用户会 对系统做什么；而应该从一个 客观的角度，根据用户需求挖掘出领域内的相关事物，思考 这些事物的本质关联及其变化规律 作为出发点去思考问题。 领域模型是 排除了人之外的客观世界模型 ，包含了人所扮演的参与者角色。但是一般情 况下不要让参与者角色在领域模型中占据主要位置，否则各个系统的领域模型将变得没有 差别，因为软件系统就是一个人机交互的系统，都是以人为主的活动记录或跟踪。例如： ? 论坛中如果以人为主导，那么领域模型就是：人发帖，人回帖，人结贴，等等； ? 货物托运系统中如果以人为主导，就变成了：托运人托运货物，收货人收货物，付款人 付款，等等； 以一个货物运输系统为例子简单说明一下。在用户需求相对明朗之后，这样描述领域模型： ? 一个 Cargo（货物）涉及多个 Customer（客户，如托运人、收货人、付款人） ，每个 Customer 承担不同的