领域驱动设计核心

转载

领域驱动设计(DDD)部分核心概念的个人理解

  1. 领域驱动设计(DDD)是一种基于模型驱动的软件设计方式。它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题。Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧。只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型。如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大。
  2. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发。在迭代过程中,强调开发人员与领域专家需要保持密切的合作关系。极限编程假设我们能通过不断快速重构完善设计。所以,对开发人员的要求非常高。
  3. 领域驱动设计提出了一套核心构造块(Building Blocks,如聚合、实体、值对象、领域服务、领域工厂、仓储、领域事件,等),这些构造块是对面向对象领域建模的一些核心最佳实践的浓缩。这些构造块可以使得我们的设计更加标准、有序。
  4. 统一语言(Ubiquitous Language),是领域驱动设计中一个非常重要的概念。任何一个领域驱动设计的项目,都需要一种通用语言,一套通用的词汇。因为没有通用的语言,就没有一致的概念,沟通就会遇到障碍,最后的领域模型和软件也就无法满足领域内的真实业务需求。通用语言是领域专家和开发人员在对领域问题的沟通、需求的讨论、开发计划的制定、领域模型的设计,以及开发人员之间对领域模型的具体编码落地实现,等一系列过程中,所有人员使用的一种通用语言。话句话说,就是无论是沟通时所用的词汇、还是领域模型中的概念、还是代码中出现的类名与方法,只要是相同的意思,那就应该使用相同的词汇。可以看出,这种通用语言不是一下子就可以形成,而是在一个各方人员讨论的过程中,不断发现、明确,与精炼出来的。
  5. 领域模型是领域驱动设计的核心。统一语言中的所有关键词汇,在领域模型上应该都能找到。各方人员沟通时,都应该以领域模型为基础。通过讨论的不断深入,大家对领域的认识也会不断深入,领域模型也会不断得到完善,统一语言的词汇也会不断丰富和精准。需要特别强调的是,开发人员应该尽量保证代码实现和领域模型相绑定,时刻保持代码与模型的一致。如果不绑定,那代码就会慢慢和模型相脱节,就会出现像我们以前那样的设计文档和代码相脱节一样的问题,甚至模型还会起到误导作用。通过这样一种思路,我们确保语言、模型、代码三者紧密绑定,确保最后实现出来的软件可以准确无误的实现业务需求,并且还能让我们的软件可以快速的和业务同时演进。而不像传统的开发方式那样,分析、设计、实现三个阶段完全脱节,最后出来的软件没有很好的满足业务需求,也不能在未来很快的跟业务需求一起演进。所以,领域模型同时承载了分析的结果和设计的结果,这里的分析是指对领域内业务需求的分析,设计是指对模型的设计以及软件的设计。所以,我们的领域模型,不能只考虑业务需求,还要同时考虑软件设计的原则,是一种综合考虑的、平衡的设计结果。
  6. 领域模型可以复用,因为特定的领域模型解决的都是某个特定的问题域;比如淘宝网有个商品中心,有个商品模型,核心概念有商品分类、商品;商品模型负责解决电子商务领域中的商品目录(Product Catalog)子域。后来阿里又出了个天猫,也会有商品中心,但是这两个商品中心基本是一样的问题域。所以,我们可以复用之前淘宝实现的商品中心领域模型,并复用之前淘宝商品中心的解决方案,来解决天猫的商品维护和展示。当然,这个只是我个人的认识,一个例子。具体阿里是否是一个商品中心同时解决淘宝和天猫的业务,没具体调研过。
  7. Bounded Context,属于一种软件构件,作用是用来对领域模型进行划分。Bounded Context有两层含义:
    • Bounded,即有边界的,表示领域模型有边界;这个边界定义了模型的适用范围,以便让负责该模型的团队知道什么该在模型中实现,什么不该;
    • Context,即领域模型的产生是在某个上下文中产生的;上下文是一个和环境相关的概念。比如一次头脑风暴会议大家达成了一个模型,那这次会议的讨论就是该模型的上下文;比如某本书中谈到了某个东西,那这个东西的上下文就是那本书,那个东西要有意义的前提离不开那本书这个上下文;所以,上下文是模型有意义的前提;
  8. 领域建模的方法有很多种,我分享一下自己的一种基于场景为核心的分析方法。大概的思路是:
    • 通过与领域专家和业务需求人员沟通,找出领域中的关键业务场景;
    • 针对每个业务场景分析出有哪些场景参与者,哪些参与者以对象(聚合)的形式参与,哪些参与者以服务的形式参与;
    • 分析每个场景参与者对象的基本状态特征;
    • 分析每个场景参与者对象分别扮演什么角色参与场景,整个场景的完整交互过程是怎样的,对象在参与场景的过程中执行了哪些交互行为;
    • 分析如何记录和跟踪这一次交互行为,分析这次交互行为会产生哪些额外的信息;
    • 上面,只是简单列了一下条目,具体的描述,请参看我的另一篇文章,有详细的叙述。
  9. 关于领域(Domain)、领域模型(Domain Model)、边界上下文(Bounded Context)的关系
    • 领域就是问题域,问题空间;
    • 领域模型是一种模型,表达了领域中哪些业务需求以及业务规则必须被满足;
    • 每一个领域中的问题,都会有一个对应的领域模型去解决;
    • Bounded Context的作用是用来对领域模型进行划分;
    • 划分领域就是对问题空间的划分,通俗的理解,就是将大问题拆分为小问题;
    • 划分Bounded Context就是将一个大的领域模型划分为多个小的领域模型;
    • 可以把Bounded Context看成是一种解决方案空间,所以,Bounded Context也可以理解为是对解决方案空间的划分;
    • 理论上,一个Domain可能会对应多个Bounded Context;同样,一个Bounded Context可能也会对应多个Domain;所以他们之间没有绝对的关系。主要是他们划分的依据不同,一个是针对领域(问题空间),一个是针对领域模型(解决方案空间);理想情况,一个Domain最好对应一个Bounded Context;
  10. 关于Domain、Sub Domain、Core Domain、Generic Domain,以及Shared Kernal的理解:
    • 一个领域(Domain)会拆分为多个子领域(Sub Domain);
    • 子领域中最核心(最重要)的那个叫Core Domain;我们应该讲团队的核心资源用在核心子域上,因为它是产品成败的关键;
    • 除了Core Domain外,其他的是支撑子域(Supporting Subdomain);
    • 有些支撑子域比较特殊,因为它解决的是一类通用问题,比如账号和权限;这类子域我们叫做通用子域(Generic Subdomain);通常,通用子域对应的Bounded Context,会跨域多个子域;
    • 多个子领域有时会有相交的部分,我们称作共享内核(Shared Kernel);体现到代码上,就是同一份代码,在两个领域模型中复用;
    • 一般只有Domain比较大的时候,我们才会划分出Sub Domain;
  11. 为什么一个大的领域模型需要划分?因为,通常一个大的领域模型需要多个团队合作完成。如果多个团队基于一个共同的领域模型工作,由于每个团队的关注点不同,且一些看似叫法一样的概念,对于不同的团队,其背后的意思完全不同。所以,这样的概念含义模糊会给团队以及成员之间的合作带来很大的困扰。所以,我们需要通过一种手段(Bounded Context),将领域模型划分为不同的部分,确保同一个Bounded Context内的领域模型所表达的概念含义明确。然后,同一个Bounded Context下面,相关人员都使用一种统一的语言,以此来保证团队成员之间沟通能畅通无阻;

分类: DDD 理论积累

时间: 2024-10-12 14:09:10

领域驱动设计核心的相关文章

领域驱动设计-1-概述

领域驱动设计 随着计算机的普及,软件的发展也从一开始的单一计算,变为大规模,多功能的集合.这也就对软件开发的效率,规模,可维护性提出了更多的要求,针对于软件不同的发展阶段,它的开发模式也是一个逐渐演变的过程: 瀑布开发模式 -> 敏捷开发模式 -> 领域驱动设计 -> 微服务 -> ... **瀑布开发模式**:强调软件规范,使用工程管理思想来管理软件.通过严格的流程分工:需求分析->设计->开发->测试->运维.职能的明确可以提高节点内部的执行效率,针对小

领域驱动设计(DDD)部分核心概念的个人理解(转)

领域驱动设计(DDD)是一种基于模型驱动的软件设计方式.它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题.Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧.只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型.如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发.在迭代过程中,强调开发人员与领域专家

领域驱动设计(DDD)部分核心概念的个人理解

领域驱动设计(DDD)是一种软件设计的思考方式.它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题.Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧.只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型.如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发.在迭代过程中,强调开发人员与领域专家需要保持

领域驱动设计 软件核心复杂性应对之道 读书笔记

问题: 1.  何为领域驱动设计(DOMAINDriven DESIGN)? 2.  UBIQUITOUS LANGUAGE(领域通用语言)应该是如何去描述 3. 作者:Eric Evans 第二部分 模型驱动设计的构造块   第四章 分离模型 分层架构如图: 而主要的业务模型及在领域层. 第五章 软件中所表示的模型 模型主要包括Entity.Value Object和service 问题: Entity.Value Object和Service是如何定义的? 它们是如何进行区分和划分的? EN

解构领域驱动设计(二):领域驱动设计的核心之分层架构

反映业务规则的代码是整个软件的核心,但是它一般只占很小的一部分,在传统的基于贫血模型的分层软件架构中,业务规则可能分散到各个层.各个代码段,从而使得通过代码来还原业务规则或者保证代码与业务规则一致将变得非常困难.DDD分层架构的核心思想就是将所有业务规则的代码抽取到领域层,保证领域层的编码与领域模型是完全一致的. 下图是DDD的分层架构.?我将通过代码来演示这个新的分层架构. 1 应用层 应用层在这里非常的简单清晰,它仅仅是将基础设施层.领域层提供的功能装配起来完成任务,这一层的代码逻辑非常简单

《领域驱动设计 软件核心复杂性应对之道》 - 书摘精要

(序) 领域模型的最大价值是它提供了一种通用语言,这种语言是将领域专家和技术人员联系在一起的纽带: (P2) 模型是一种知识形式,他对知识进行有选择的简化和有目的的结构化: (P33) 面向对象编程之所以功能强大,是因为它基于建模范式,并且为模型构造提供了实现方式: (P48) 领域驱动设计只有应用在大型项目上才能产生最大的收益,而这也确实需要高超的技巧: (P70) 在大型系统中,中等粒度的.无状态的 Service 更容易被重用,因为它们在一个简单的接口背后封装了重要的功能: 细粒度的对象可

我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践

写在前面 插一句:本人超爱落网-<平凡的世界>这一期,分享给大家. 阅读目录: 关于DDD 前期分析 框架搭建 代码实现 开源-发布 后记 第一次听你,清风吹送,田野短笛:第一次看你,半弯新湖,鱼跃翠堤:第一次念你,燕飞巢冷,释怀记忆:第一次梦你,云翔海岛,轮渡迤逦:第一次认你,怨江别续,草桥知己:第一次怕你,命悬一线,遗憾禁忌:第一次悟你,千年菩提,生死一起. 人生有很多的第一次:小时候第一次牙牙学语.第一次学蹒跚学步...长大后第一次上课.第一次逃课.第一次骑自行车.第一次懂事.第一次和喜

DDD领域驱动设计基本理论知识总结

领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见这篇文章. 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型:由领域模型驱动软件设计,用代码来实现该领域模型:

(转载)浅谈我对DDD领域驱动设计的理解

原文地址:http://www.cnblogs.com/netfocus/p/5548025.html 从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故