ddd领域驱动设计面试题「事业单位面试真题」

今天给大家普及一下ddd领域驱动设计面试题「事业单位面试真题」相关知识，最近很多在问ddd领域驱动设计面试题「事业单位面试真题」，希望能帮助到您。

1. 什么是领域（Domain）

任何一个系统都会属于某个特定的领域，例如：

论坛是一个领域：要做一个论坛，那这个论坛的核心业务是确定的：比如用户发帖、回帖等核心基本功能；电商系统是一个领域：只要是电商领域的系统，那核心业务就是：商品浏览、购物车、下单、减库存、付款交易等核心环节；

2.界限上下文（Bounded Context）

通常来说，一个领域有且只有一个核心问题，我们称之为该领域的『核心子域』。在核心子域、通用子域、支撑子域梳理的同时，会定义出子域中的『限界上下文』及其关系，用它来 阐述子域之间的关系 。界限上下文可以简单理解成一个子系统或组件模块。

例如：下图是对酒店管理的子域和界限上下文的梳理：

3. 领域模型（Domain Model）

领域驱动设计（Domain-Driven Design）分为两个阶段：

以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；由领域模型驱动软件设计，用代码来实现该领域模型；

领域模型具有以下特点：

对具有某个边界的领域的一个抽象，反映了领域内用户 业务需求的本质 。它属于『解决问题空间』。领域模型是有边界的，只反应了我们在领域内所关注的部分，包括 实体概念（如：货物，书本，应聘记录，地址等），以及 过程概念；提高软件的 可维护性，业务可理解性以及可重用性。领域模型确保了我们的软件的业务逻辑都在一个模型中，帮助开发人员相对平滑地将领域知识转化为软件构造；贯穿软件 分析、设计、开发 的整个过程。领域专家、设计人员、开发人员面向同一个模型进行交流，彼此共享知识与信息，所以可以防止需求走样，让软件开发人员做出来的软件真正满足需求；要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型；为了让领域模型看的见，使用的常用表达领域模型的方式：图、代码或文字；重要性：领域模型是整个软件的核心，是软件中最有价值和最具竞争力的部分；设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化；

4. 领域通用语言

由软件专家和领域专家合作开发一个领域的模型是有必要的。开发过程中， 开发人员以类、算法、设计模式、架构等进行思考与交流。但领域专家对此一无所知，他们对技术上的术语没有太多概念，只了解特有的领域专业技能，例如：在空中交通监控样例中，领域专家知道飞机、路线、海拔、经度、纬度，他们有自己的术语来讨论这些事情。软件专家和领域专家交流过程中，需要做翻译才能让对方理解这些概念。

领域驱动设计的一个核心原则是使用一种基于模型的语言。使用模型作为语言的核心骨架，要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样，这种语言被称为『通用语言』

5. 使用的模式

5.1. 总览图

5.2. 聚合及聚合根（Aggregate，Aggregate Root）

聚合定义了一组具有 内聚关系 的相关对象的集合，以及对象之间清晰的所属关系和边界，避免了错综复杂的难以维护的对象关系网的形成。我们把聚合看作是一个修改数据的单元。

聚合有以下特点：

每个聚合有一个根和一个边界：根是聚合内的某个实体；边界定义了一个聚合内部有哪些实体或值对象；聚合根是外部可以保持对聚合引用的唯一元素，负责与外部其他对象打交道并维护自己内部的业务规则。聚合内部的对象之间可以相互引用，但是聚合外部如果要访问聚合内部的对象时，必须通过聚合根开始导航，绝对不能绕过聚合根直接访问聚合内的对象；聚合内除根以外的其他实体的唯一标识都是本地标识，也就是只要在聚合内部保持唯一即可，因为它们总是从属于这个聚合的；聚合内部的对象可以保持对其他聚合根的引用；删除一个聚合根时必须同时删除该聚合内的所有相关对象，因为他们都同属于一个聚合，是一个完整的概念；基于聚合的以上概念，我们可以推论出从数据库查询时的单元也是以聚合为一个单元，不能直接查询聚合内部的某个非根的对象；

6.设计领域模型时一般步骤

根据需求建立初步的领域模型，识别明显的领域概念和之间的关联（1:1, 1:n的关系），用文字精确没有歧义的描述出每个领域概念的含义；分析主要的软件功能，识别主要的应用层的类，这样有助于及早发现哪些是应用层的职责，哪些是领域层的职责；进一步分析领域模型，识别出实体、值对象、领域服务；分析关联，通过对业务的深入分析和软件设计原则及性能方面的权衡，明确关联的方向，去掉一些不需要的关联；找出聚合边界及聚合根，在分析过程中会出现难以清洗判断的选择问题，这就依赖平时分析经验的积累了；为聚合根配置仓储，一般情况下为一个聚合分配一个仓储，此时设计好仓储的接口即可；遍历所有场景，确定设计的领域模型能有效解决业务需求；考虑如何创建实体和值对象，是通过工厂还是构造函数；重构模型，寻找模型中有疑问或蹩脚的地方，比如思考：聚合的设计是否正确，模型的性能等等；

领域建模是一个不断重构，持续完善的过程，大家会在讨论中将变化的部分反映到模型中，从而模型不断细化并朝正确的方向走。

总结：

DDD是什么？

喜欢DDD的人觉得

•DDD是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的规范过程，使得你的设计思路能够更加清晰，设计过程更加规范。

•DDD尤其善于处理与领域相关的高复杂度业务的产品研发，通过它可以为你的产品建立一个核心而稳定的领域模型内核，有利于领域知识的传递与传承。

•DDD强调团队与领域专家的合作，能够帮助团队建立一个沟通良好的团队组织，构建一致的架构体系。

•DDD强调对架构与模型的精心打磨，尤其善于处理系统架构的演进设计。

•DDD的思想、原则与模式有助于提高团队成员的面向对象设计能力与架构设计能力。

•DDD与微服务架构天生匹配，无论是在新项目中设计微服务架构，还是将系统从单体架构演进到微服务设计，都可以遵循领域驱动设计的架构原则。

DDD希望解决的问题是？

复杂程度已经超出了个人所能够理解、分析和解决的范围。

“复杂性”的典型特征：

•业务流程长

•业务场景多

•业务概念多