首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

领域驱动设计与模型驱动架构

领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法论,旨在帮助开发人员更好地理解和应对复杂业务领域中的挑战。它强调将业务领域作为软件设计的核心,通过深入理解业务需求和业务规则,将领域模型作为软件系统的核心构建模块。

领域驱动设计的主要概念包括:

  1. 领域模型(Domain Model):领域模型是对业务领域的抽象和建模,它由实体(Entity)、值对象(Value Object)、聚合根(Aggregate Root)、领域服务(Domain Service)等组成。领域模型应该准确地反映业务领域的规则和行为。
  2. 聚合根(Aggregate Root):聚合根是领域模型中的一个重要概念,它是一组相关对象的根实体,负责维护聚合内部的一致性和完整性。通过聚合根,可以对整个聚合进行操作和管理。
  3. 领域事件(Domain Event):领域事件是领域模型中的一个重要概念,它表示领域中发生的某个重要的业务事件。领域事件可以被其他领域对象订阅和处理,用于实现领域间的解耦和业务流程的协调。
  4. 领域驱动设计的分层架构:领域驱动设计通常采用分层架构,包括用户界面层(UI)、应用层(Application)、领域层(Domain)、基础设施层(Infrastructure)等。每一层都有不同的职责和关注点,通过良好的分层设计可以实现系统的可维护性和可扩展性。

领域驱动设计的优势包括:

  1. 更好的业务理解:通过深入理解业务领域,开发人员可以更准确地把握业务需求,避免理解偏差和沟通障碍。
  2. 更好的代码质量:领域驱动设计强调模型的准确性和一致性,可以帮助开发人员编写高质量的代码,减少bug和重构的成本。
  3. 更好的团队协作:领域驱动设计鼓励开发团队与领域专家密切合作,通过共同理解和共同设计,可以提高团队的协作效率和开发质量。
  4. 更好的系统可扩展性:通过良好的领域模型设计,可以实现系统的松耦合和可扩展性,方便后续的功能迭代和系统演进。

领域驱动设计在各种业务场景中都有应用,特别适用于复杂业务领域和需求频繁变更的项目。以下是一些腾讯云相关产品和服务,可以辅助实现领域驱动设计:

  1. 云服务器(Elastic Cloud Server,ECS):提供可弹性伸缩的云服务器实例,用于部署和运行领域驱动设计的应用程序。
  2. 云数据库MySQL版(TencentDB for MySQL):提供稳定可靠的云数据库服务,用于存储和管理领域模型的数据。
  3. 云原生容器服务(Tencent Kubernetes Engine,TKE):提供高度可扩展的容器化部署和管理平台,方便将领域驱动设计的应用程序进行容器化部署。
  4. 人工智能服务(AI Lab):提供丰富的人工智能服务,如语音识别、图像识别等,可以与领域驱动设计的应用程序进行集成,实现更智能化的业务处理。
  5. 物联网平台(IoT Hub):提供全面的物联网解决方案,用于连接和管理物联网设备,可以与领域驱动设计的应用程序进行集成,实现物联网业务的支持。

请注意,以上仅为腾讯云相关产品和服务的示例,其他云计算品牌商也提供类似的产品和服务,具体选择应根据实际需求和项目情况进行评估。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

企业架构领域驱动设计的融合

不管这些领域资产是通过核心模型、服务还是其他组件形式,都需要对准转型方向的企业战略,并在战略指导下做到可复用业务能力的识别沉淀。...这个过程可以是计划式的,也可以是演进式的;可以是分解为服务的粒度,也可以是能力中心的粒度;可以采用领域驱动设计建立核心领域模型,也可以建立自治的微服务,也可以是中台的能力规划战略。...因此,企业架构领域驱动设计是完全能够融合在一起的,促进这一融合的催化剂是数字化转型,呼唤这种融合的需求来自于相对高高在上的企业架构需要具备落地的能力,至于这种融合为何在现在开始提出或得到重视,是因为当下这个时代...我的一个粗浅想法,是希望借鉴DDD的方法思想,寻求对企业架构做必要的精简和简化,核心价值仍然是领域(业务)驱动,然后尝试建立不同层次的架构体系,即建立组织级系统级的架构,让企业架构方法DDD方法各司其职...从学习路线看,我算是自下而上的狂飙猛进,不再满足于领域驱动设计的系统层次,要向上开始向企业顶层设计“逆袭”,之后,不是高高在上去俯视IT众生,而是沉下心来,完成二者的真正融合——既要做得了规划,还能写得出方案

24520

DDD 领域驱动模型设计中的分层架构

然而,在领域驱动设计中,层次和包的划分看起来与我们的结构又有一定区别,本文主要讨论DDD中的分层架构及每层的意义,以及传统的三层架构的区别。 1....为什么要分层 软件设计中分层的设计随处可见,但是分层能带来什么好处呢?或者说,我们为什么要考虑分层架构呢?...首先我们来看一下Evans在《领域驱动设计》中提到的分层架构。 ? image 问:为什么要分成这样的四层? 分层主要目的是为了简化复杂性,系统中最复杂的部分应该就是我们的业务逻辑。...所有具体平台、框架相关的实现会在Infrastructure中提供,避免三层特别是Domain层掺杂进这些实现,从而“污染”领域模型。...模型的形态 不同的架构、不同的层、不同的应用场景中有着不一样的建模需求,因此表达相同概念的模型可能会有不同的形态,例如: 充血模型领域模型架构中包含了领域逻辑和领域属性的领域模型

6.3K50
  • DDD领域驱动设计 — 贫血模型充血模型

    前言 要想深入掌握和了解 DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”: 贫血模型即事务脚本模式。 充血模型领域模型模式。...贫血领域模型的根本问题是,它引入了领域模型设计的所有成本,却没有带来任何好处。最主要的成本是将对象映射到数据库中,从而产生了一个O/R(对象关系)映射层。...正如martin在企业应用架构模式一书中说到的,领域模型并不一定是最好的工具。 将行为放入领域模型,这点和分层设计领域层、持久化层、展现层等)并不冲突。...我怀疑是因为大多数人并没有使用过一个设计良好的领域模型,特别是那些以数据为中心的开发人员。...举个简单的J2EE案例,设计一个用户(User)相关功能。 传统的设计一般是: 类:User+UserManager; 保存用户调用:userManager.save(User user)。

    78131

    领域驱动设计】Redux 和领域驱动设计

    Redux 的创建者 Dan Abramov 说他不知道什么是领域驱动设计。尽管如此,令人印象深刻的是 Redux DDD 的相似之处。...理解两者,我们可以提供更好的实现;来自不同世界的两种方法相互碰撞并利用相同的设计原则。 领域驱动设计 领域驱动设计是一种软件建模技术,旨在创建强大的微服务架构以及集成多个现有解决方案。...Eric Evans 最初于 2003 年在《领域驱动设计:解决软件核心中的复杂性》一书中提出它。目前,DDD 有更多的书籍、更多的示例,并且已被证明可以有效地扩展和保持大型系统中的高级性能。...Redux Redux 领域驱动设计有着惊人的关联。虽然它不共享相同的术语,但想法是存在的。Redux 几乎是功能范式中 DDD 策略的实现。...尽管它们是从不同的抽象和不同的背景创建的,但它们都受益于相同的架构原则。 主要区别在于领域事件。这个概念在 Redux 中并没有明确存在。它有后果,可能会在进一步的文章中进行研究。

    1.5K30

    架构视角 - DDD、TDD、MDD领域驱动、测试驱动还是模型驱动

    提出问题     「领域驱动设计」之于微服务,好比麦当劳之于汉堡(个人更喜欢肯德基,汉堡要大些,麦当劳的汉堡,想吃顿饱饭,请先给我上6个?)。...DDD是Domain-Driven Design领域驱动设计。但是TDD和MDD的D意思是Development开发的意思。TDD对应测试驱动开发,MDD对应模型驱动开发。...这就是为什么很多大佬在大谈特谈「领域」,但是测试驱动模型驱动其实也都在用,但谈的少些。因为这是我等实际一线写代码的同学才用的。...解决问题 在Eric Evans的《领域驱动设计-软件核心复杂性应对之道》中第一节的消化知识开始就开始建模。在我们平时的设计开发中,在描述总体设计思路也需要用模型也表示。...fr=aladdin 这些本质上是模型驱动开发的一种方法。现在很多公司和组织在研究一些更方便建模的工具。基于MDA(模型驱动架构)的工具涌现的比较多了,但是基本都是收费的。

    4K40

    【系统架构】可视化领域驱动设计

    说明:本图摘自熊子川博客 获得Context并划分领域 假设我们要开发一个电子商务网站,我们就可以通过商业画布来驱动出这个产品应该具有哪些功能,它的客户有哪些等,在绘制了场景图后,可以初步得到这样的Bounded...Hexagon架构并不深入关注内部边界中领域部分,仅仅是简单的划分为ApplicationDomain两层。但它有助于我们获得基础设施层以及相关集成点的包结构。我们要合理地运用六边形架构。...它更贴近应用逻辑架构,并可以驱动我们去发现诸多集成点,寻找集成模式。内外边界的分离也有助于我们将业务逻辑应用逻辑分离开。这实际上符合“关注点分离”的架构原则。...而对于支持并发的领域对象访问而言,则采用了Active Object模式,并引入Leader/Followers并发模型来获得可扩展。...目前,我针对可视化架构设计的手段仍在完善之中,并已经尝试在真实项目中实践以进行验证,并希望能够找到足够简单的方法,为架构开发者提供直观而又具有体验价值的沟通方式,并能形成行之有效的设计手段。

    1.3K60

    微服务领域驱动设计架构实践总结

    2、应对复杂 不管是常说的设计模式、原则、面向对象,还是架构中常用的集群、微服务、领域驱动等,都是在寻求更合理的方案来应对业务的变化;但是没有一劳永逸的解决方法,既要做一定前瞻性的设计去预期业务,同时还要避免过度的设计影响业务进度...三、领域驱动设计 相比MVC的分层设计领域驱动设计(Domain-Driven-Design简称DDD)对于复杂业务系统的实现,提出了更加合理的解决方案,DDD模式中涉及大量专业术语和抽象概念,可以参考...1、分离模式 DDD模型在分层设计上,划分出核心的四层:接入层、应用层、领域层、基础设施层;注意这里只是单纯站在服务端的常规架构角度去看,很明显分离MVC模式中的服务实现层的逻辑: 其中领域层是关键所在...2、设计思想 领域驱动设计并不是简单的分层管理模型,涉及诸多抽象逻辑专业术语,例如:领域、界限上下文、实体、聚合、值对象等等; 2.1 领域 领域可以理解为业务场景中需要解决的问题合集,是具有范围和边界的约束...; 工厂(Factory):封装对象复杂的创建逻辑类型; 存储库(Repository):把存储、缓存、搜索等资源封装的机制,对应领域模型领域模型的核心追求目标:高内聚、低耦合;更加抽象的、复杂的设计思想

    44420

    「首席架构领域驱动设计领域驱动设计和开发最佳实践

    背景 域驱动设计(DDD)是关于将业务域概念映射到软件构件的。关于这个主题的大多数文章和文章都是基于Eric Evans的《领域驱动设计》一书,主要从概念和设计的角度覆盖了领域建模和设计方面。...架构师和开发人员应该具有很强的面向对象设计(OOD)和编程(OOP)经验。 领域驱动设计在企业架构中的角色 领域建模和DDD在企业架构(EA)中扮演着重要的角色。...支持DDD的设计模式 有几种设计模式可以帮助领域驱动设计和开发。...像AndroMDA这样的模型驱动架构(Model Driven Architecture, MDA)工具使用EMF根据架构模型生成代码。...事件驱动架构(EDA)是另一个可以在领域驱动设计中发挥作用的领域。例如,用于通知域对象实例中的任何状态更改的事件模型将有助于处理需要在域对象的状态更改时触发的事件后处理任务。

    1.6K30

    DDD领域驱动设计-充血模型、贫血领域模型

    贫血领域模型的根本问题在于,它引入了领域模型设计的所有成本,却没有带来任何好处。 最主要的成本是将对象映射到数据库中,从而产生了一个O/R(对象关系)映射层。...正如martin在企业应用架构模式一书中说到的,领域模型并不一定是最好的工具。 将行为放入领域模型,这点和分层设计领域层、持久化层、展现层等)并不冲突。...我怀疑是因为大多数人并没有使用过一个设计良好的领域模型,特别是那些以数据为中心的开发人员。...举个简单的J2EE案例,设计一个用户(User)相关功能。...参考 《领域驱动设计》 https://www.zhihu.com/question/20360521/answer/14891150 https://www.martinfowler.com/bliki

    82330

    DDD领域驱动设计实战-分层架构

    开发设计时,不要将本该放在领域层的业务逻辑放到应用层。因为庞大的应用层会使领域模型失焦,时间一长微服务就会演化为传统MVC三层架构,导致业务逻辑混乱。...领域层主要体现领域模型的业务能力,它用来表达业务概念、业务状态和业务规则。 领域模型的业务逻辑主要由实体和领域服务实现: 实体采用充血模型 实现所有之相关的业务功能。...注意定义好聚合间的代码边界 架构演进后,微服务1从最初包含聚合a、b、c,演进为包含聚合b、c、d的新领域模型和微服务 可见,好的聚合和代码模型的边界设计,可让你快速应对业务变化,轻松实现领域模型和微服务架构演进...由于层间松耦合,我们可以专注于本层的设计,而不必关心其它层,也不必担心自己的设计会影响其它层。可以说,DDD成功地降低了层层之间的依赖。 其次,分层架构使得程序结构变得清晰,升级和维护更加容易。...参考 《实现领域驱动设计》 DDD分层架构:有效降低层层之间的依赖

    1.9K42

    领域驱动系列五模型驱动设计的构造块

    一、简介 为了保证软件实现的简洁性,并且模型保持一致,不管实际情况有多复杂,必须使用建模和设计的最佳实践,即让通过我们的编程技术(设计模型、指责驱动、契约式设计)充分地体现领域模型,并保持模型地健壮性和可扩展性...,而不是单单地实现模型.某些决策设计能和模型紧紧地结合,这种结合要求我们注意每个元素地细节....开发一个好的领域模型是一门艺术,而模型中的各个元素的实际设计和实现则相对系统化,将领域设计(也可以是软件系统中的其他关注点)软件系统中的其他关注点(也可以是领域设计)分离使整个领域模型非常的清晰.根据不同模型的指责...上图展示的模型驱动设计的基本构造块,当然实际开发中可能不止这些内容,可能还会有施加在实体上的一些契约还有一些特殊的计算规则、可能还有有一些复杂的实体运算,这些运算可能还需要使用一些设计模式去设计等等.但这个基本的构造...summary> /// 用户聚合根工厂,按照计价策略生成对应的用户实体,这个类会暴露给外面的业务结构使用 /// 将业务逻辑的处理交给工厂类,这样做的好处,是减轻控制器的压力,也符合领域驱动设计的理念

    91510

    《解构领域驱动设计架构映射篇

    价值需求中利益相关者、系统愿景和系统范围可映射为系统上下文,业务活动通过对业务相关性的归类归纳可映射为限界上下文,二者又是构成系统架构的重要层次,前者勾勒出解空间的控制边界,后者勾勒出领域模型的知识边界...,组成了一个稳定而又具有演进能力的领域驱动架构。...限界上下文是顺应业务变化进行功能分解的软件元素,菱形对称架构规定了限界上下文之间、限界上下文外部环境之间的关系,由系统分层架构模式菱形对称架构模式组成的领域驱动架构风格则是指导架构设计演进的原则。...这些内容符合架构的定义,同时也是对控制软件复杂度的呼应。 领域建模要在架构的约束下进行,系统上下文和限界上下文的边界对领域模型起到了设计约束的作用。...因此,架构映射是领域建模的前提,也可以认为是战略对战术的设计指导。 说明:许多朋友在询问《解构领域驱动设计》何时可以出版购买?

    47010

    领域驱动设计

    关于领域驱动设计 这篇文章参考了Eric Evans《领域驱动设计》一书以及Jimmy Nilsson《以C# .NET为例运用领域驱动设计和模式》,二者详细描述了领域驱动设计的核心概念、技术和模式。...值得注意的是,DDD还鼓励将其他领域的概念收入囊中,比如测试驱动开发,设计模式的使用,以及持续重构。 代表模型 领域驱动设计的最主要目的是为了设计和创造出富有表达力的模型。...使用具体实例 使用具体实例领域名专家进行协作往往更容易。通常,使用行为驱动开发(BDD)故事和场景模板来描述领域示例是很方便的。我们上述场景使用具体实例的版本,用BDD模板进行改写。...应用架构设计的重点在于创建行为丰富的领域模型时,那么相应的架构设计必须保证模型不受基础设施的影响。通常来说,分层架构可以将领域系统中的其他层分隔开,并且每一层只能感知它下一层的存在。...用户界面层 负责构建用户界面并管理领域模型的交互。典型的应用是MVC模式。 应用层 允许视图层领域层协作的中间层。注意:这是容易聚集比较散乱的行为,诸如“事务脚本”风格的代码。

    99590

    领域驱动设计

    领域驱动设计尤其善于处理领域相关的高复杂度业务的产品研发,通过它可以为你的产品建立一个核心而稳定的领域模型内核,有利于领域知识的传递传承。...领域驱动设计强调团队领域专家的合作,能够帮助团队建立一个沟通良好的团队组织,构建一致的架构体系。 领域驱动设计强调对架构模型的精心打磨,尤其善于处理系统架构的演进设计。...领域驱动设计的思想、原则模式有助于提高团队成员的面向对象设计能力架构设计能力。...领域驱动设计微服务架构天生匹配,无论是在新项目中设计微服务架构,还是将系统从单体架构演进到微服务设计,都可以遵循领域驱动设计架构原则。...在分层架构中,各层之间该如何协作?如果出现了依赖,该如何解耦?仍然需要从重用变化的角度去思考设计决策。 为什么同样遵循领域驱动设计,不同的系统会设计出不同的架构

    58030

    领域驱动设计中的架构要素

    多数时候,领域驱动设计的分层架构并不能清晰表达各模块之间的依赖关系,以及这些模块在分层架构中所处的位置。...南向网关要特殊一些,它是打通应用层或领域外部资源(数据库、消息队列、第三方服务)的通道。根据整洁架构设计原则,我们不能让内层依赖外层,以保证内层的纯粹性稳定性。...以下是对代码结构的说明: application:对应了领域驱动设计的应用层,主要内容为该限界上下文中所有的应用服务。...domain:对应了领域驱动设计领域层,但是我将repositories单独分了出来,目的是为了更好地体现它在基础设施层扮演的外部资源打交道的网关语义。...归根结底,在运用DDD进行架构设计,并通过BC映射到微服务设计时,要遵循两方面的设计原则。 一个是普适性的架构设计原则,例如整洁架构、分而治之思想、关注点分离、最小知识法则等。

    3.5K40

    前端架构之 React 领域驱动设计

    来自前端备忘录 - 江湖术士[1] https://hqwuzhaoyi.github.io/2021/01/14/74.HookDDD/ 领域驱动,各自只管各自的模块,顶层再来进行组装和分配 坚持根据特性区命名目录...可以作为 “模块标识” 这个有共同单例 Service 的一系列组件,被称为模块,它们有自己的 “限界上下文”,并且,视图,逻辑,样式都在其中,如果这个模块是按照功能划分的,那么这种 SOA 实现被称为 领域驱动设计...他决口不提 面向对象,领域驱动,和之前的设计失误,是因为他需要顾及影响和社区生态,但是使用者不要被这些欺骗!...,Service/Module 的时候,你应该主动抛弃所有类似 状态管理 一定要写纯函数 副作用要一起处理 一定要保证不变形 这之类的所有言论,因为在你手上,不仅仅只有函数式一件武器 你还有面向对象和领域驱动...用领域驱动解决高层级问题,用函数式解决低层级问题,才是最佳开发范式 也就是说,函数式和面向对象,没有好坏,他们只是两个关注点不同的思想方法而已 你要是被这种思想方法影响,眼里只有对错 —— 实际上是被忽悠了

    1.5K30

    前端架构之 React 领域驱动设计

    领域驱动,各自只管各自的模块,顶层再来进行组装和分配 坚持根据特性区命名目录。 坚持为每个特性区创建一个 NgModule。...可以作为 “模块标识” 这个有共同单例 Service 的一系列组件,被称为模块,它们有自己的 “限界上下文”,并且,视图,逻辑,样式都在其中,如果这个模块是按照功能划分的,那么这种 SOA 实现被称为 领域驱动设计...他决口不提 面向对象,领域驱动,和之前的设计失误,是因为他需要顾及影响和社区生态,但是使用者不要被这些欺骗!...,Service/Module 的时候,你应该主动抛弃所有类似 状态管理 一定要写纯函数 副作用要一起处理 一定要保证不变形 这之类的所有言论,因为在你手上,不仅仅只有函数式一件武器 你还有面向对象和领域驱动...用领域驱动解决高层级问题,用函数式解决低层级问题,才是最佳开发范式 也就是说,函数式和面向对象,没有好坏,他们只是两个关注点不同的思想方法而已 你要是被这种思想方法影响,眼里只有对错 —— 实际上是被忽悠了

    2.1K21

    实现领域驱动设计pdf_领域驱动设计实例

    在上一部分,分层架构的目的是为了将业务规则剥离出来在单独的领域层中进行实现。再回顾一下领域驱动设计的分层中应用层代码的实现。...领域对象的持久化交给了基础设施层,这里,Repository目的是持久化领域对象状态。 领域驱动设计,即领域模型驱动程序设计,它的核心是保证系统的实现实际的业务规则一致,完整实现了领域模型。...它包含了两个部分:领域模型领域模型的编程实现。 在软件设计和实现过程中要充分利用领域模型设计过程中,领域模型作为业务专家的沟通语言;实现过程中,领域模型作为开发人员沟通的语言。...接下来我们要介绍如何实现模型驱动程序设计,即我们如何通过代码来实现领域模型对应的业务逻辑。领域模型的实现代码在领域层,它完整实现了领域模型的内部结构和模型之间的关系。...在《领域驱动设计》里面有一个示例,展示了转账服务的实现,转账动作实现的是从一个账户到另一个账户的资金流转,因此将转账设计领域服务TransferService里面。

    1.6K20

    领域驱动架构风格

    领域驱动架构是针对领域驱动设计建立的一种架构风格,它以领域为核心驱动力,以业务能力为核心关注点建立目标系统的架构解决方案,核心元模型为系统上下文限界上下文,并以它们为边界形成各自的架构模式:系统分层架构模式菱形对称架构模式...领域驱动架构风格充分利用了限界上下文的自治性开放性。...显然,支撑领域驱动架构风格演变能力的关键要素,正是领域驱动战略设计的核心模式——限界上下文。 领域驱动架构风格充分利用了系统上下文对解空间的边界定义,并在约束一致性的同时,保证了设计的实用性。...系统分层架构对限界上下文进行了界定规范,使得它们能够采取一致的方式提供业务能力;同时,根据限界上下文所属子领域的不同,结合具体的业务场景降低对限界上下文的设计要求,不再一视同仁地严格要求运用菱形对称架构...无论是单体架构模式、面向服务架构模式还是微服务架构模式,实则都可以遵循系统分层架构,它们之间的区别仅在于限界上下文的通信边界,如此就可以让遵循领域驱动设计的系统架构做到业务架构应用架构、数据架构的统一

    51430

    领域驱动系列四之模型驱动

    1、常规以类图作为领域模型开发存在的问题 传统型以技术为驱动的团队,往往喜欢通过类图来展示产品的模型,这样的模型往往存N个对象,这些对象往往存在复杂的关联,产品的创始人,可能能理解整个产品的架构思路,但是如果是新成员...而且假设这个类图代表的领域模型是正确的,但是当团队真正的去实现这个模型的时候,发现还是无法将这种错综复杂的模型转换成可存储可转换的事务单元.这里需要解释下,因为前面的文章介绍了,最小化抽象领域的概念,这是领域驱动设计的必然要求...领域模型种类很多,他们的目的也各有不同,且领域驱动设计要求,模型不仅能够指导前期的分析工作,而且还应该成为设计的基础,我们的代码也必须是结合模型的....而不是由IE自行处理,这样用户就变得非常的弱势,那么软件的用户可能随之减少. 6、模型驱动对于开发人员的重要性 如果在项目开发种架构师只负责搭建核心驱动程序的模型,而不参与业务模型的搭建,任由手下的开发随笔的去构建业务模型...,那么久而久之,整个产品可能可用,但是随着人事变动,或者业务模块的复杂度增大,那么最后整个领域模型可能也会因此变得不可用.所以这个过程架构师必须配合开发人员共同去构建业务领域模型,这会让开发人员意识到改变业务领域模型

    1K20
    领券