![](https://img-blog.csdnimg.cn/20201014180756918.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
架构-中台-DDD
文章平均质量分 89
大树~~
哦
展开
-
19、基于DDD的微服务代码详解
本章将深入探讨如何基于领域驱动设计(DDD)开发微服务代码,并提供具体的代码示例和详细解释。我们将基于第十八章中的请假案例进行讲解,确保每个细节都不放过。回顾第十八章中请假案例的需求和设计,我们已经拆分出两个微服务:请假服务和考勤服务。请假服务的核心业务流程如下:请假微服务使用了许多DDD的设计思想和方法,如聚合、实体、值对象、领域服务和仓储模式。请假微服务包含三个聚合:请假(leave)、人员(person)和审批规则(rule)。我们将详细解释每个聚合中的对象及其职责。聚合根是聚合的入口,负责维护聚合内原创 2024-07-29 23:13:25 · 827 阅读 · 0 评论 -
18、基于DDD的微服务设计实例
在本章基于DDD的微服务设计实例中,我们将通过一个实际的微服务设计实例,详细介绍如何基于领域驱动设计(DDD)来构建微服务架构。这个实例不仅涵盖了微服务设计的基本原则,还展示了实际应用中的具体实现细节和最佳实践。原创 2024-07-29 23:09:58 · 1031 阅读 · 0 评论 -
17、服务和数据在微服务各层的协作
在微服务架构中,服务和数据的协作是确保系统高效运行和可维护性的关键。本章详细探讨了微服务架构中的服务视图和数据视图,帮助我们理解在运行过程中这些服务和实体在各层是如何协作的。原创 2024-07-29 23:05:46 · 674 阅读 · 0 评论 -
16、DDD系列-向微服务迈进
在本章中,我们将探讨如何从传统的单体架构向微服务架构演进。这个过程需要考虑许多因素,包括微服务的驱动力、所需条件、服务粒度的确定以及系统复杂性的治理。原创 2024-07-29 23:00:43 · 562 阅读 · 0 评论 -
15、如何保证领域模型与代码模型一致
在代码中,为每个领域对象定义对应的类。// 构造方法、getter和setter方法// 构造方法、getter和setter方法// 构造方法、getter和setter方法。原创 2024-07-28 10:36:28 · 306 阅读 · 0 评论 -
14、如何⽤DDD设计微服务代码模型
在完成领域模型设计后,接下来我们就可以开始微服务的设计和 落地了。在微服务落地前,⾸先要确定微服务的代码结构,也就是我 下⾯要讲的微服务代码模型。只有建⽴了标准的微服务代码模型和代码规范后,我们才可以将 领域对象映射到代码对象,并将它们放⼊合适的代码⽬录结构中。标 准的代码模型可以让项⽬团队成员更好地理解代码,根据统⼀的代码 规范实现团队协作,也可以让微服务各层的业务逻辑互不⼲扰、分⼯ 协作、各据其位、各司其职,避免不必要的代码混淆,还可以让你在 微服务架构演进时,轻松完成代码重构。原创 2024-07-22 23:15:05 · 829 阅读 · 0 评论 -
13、如何用DDD重构中台业务模型
领域驱动设计(Domain-Driven Design,DDD)是一种设计方法论,旨在通过紧密结合业务领域和软件设计来解决复杂业务问题。DDD提倡从业务需求出发,建立清晰的领域模型,并根据该模型设计系统架构。DDD的核心思想包括领域模型、限界上下文(Bounded Context)和聚合(Aggregate)等概念。原创 2024-07-16 09:21:44 · 603 阅读 · 0 评论 -
12、如何用事件风暴构建领域模型
事件风暴是一种高效的领域建模技术,通过将领域专家和开发团队聚集在一起,共同探索和识别业务领域中的关键事件和行为,从而构建出清晰的领域模型。通过对事件风暴的深入理解和实践应用,我们可以更好地设计和构建复杂的分布式系统,更加灵活地应对快速变化的业务需求,提升系统的可维护性和扩展性。事件风暴(Event Storming)是一种高效的领域建模技术,通过将领域专家和开发团队聚集在一起,共同探索和识别业务领域中的关键事件和行为,从而构建出清晰的领域模型。例如,谁触发了这个事件,谁是事件的参与者,谁是事件的受益者等。原创 2024-07-14 22:37:30 · 914 阅读 · 0 评论 -
11、中台-DDD-几种微服务架构模型对比分析
其核心思想是通过明确各层的职责和边界,来实现系统的高内聚、低耦合。虽然DDD分层架构、洋葱架构和六边形架构在表现形式上存在很大差异,但它们的核心设计思想是一致的,都是为了实现核心业务逻辑和技术实现细节的分离和解耦。在微服务设计中,需要通过仓储模式和依赖倒置设计方法,将业务逻辑与基础资源逻辑解耦,减少基础设施变更对业务逻辑的影响,提升系统的可维护性和扩展性。通过对三种架构模型的深入理解和实践应用,我们可以更好地设计和构建复杂的分布式系统,更加灵活地应对快速变化的业务需求,提升系统的可维护性和扩展性。原创 2024-07-11 22:47:01 · 735 阅读 · 0 评论 -
10、DDD分层架构
DDD分层架构其实也在不断发展和演进。早期的DDD分层架构是一种各层都依赖于基础层的传统四层架构,后来这种四层架构进一步优化,实现了各层对基础层的解耦和依赖倒置。在最早的传统四层架构中,基础层被其他层依赖,位于最核心的位置,是其他各层依赖的核心。但实际上领域层才是软件的核心,所以这种依赖关系是有问题的。后来就采用了依赖倒置设计,各层服务通过仓储接口访问基础层,从而优化了传统的DDD四层架构,实现了DDD各层对基础层的解耦。我们本章要重点讲解的就是优化后的DDD分层架构。原创 2024-07-08 23:18:14 · 1062 阅读 · 0 评论 -
9、领域事件:解耦微服务的关键
领域事件是指在领域模型中发生的事件,它们通常代表着领域中重要的业务变化。例如,在游戏中,领域事件可以表示玩家升级、任务完成、物品掉落等关键行为。这些事件可以触发后续的业务逻辑,例如奖励发放、统计更新、排行榜刷新等。原创 2024-07-08 07:06:52 · 765 阅读 · 0 评论 -
8、聚合和聚合根:怎样设计聚合
在本章中,我们详细探讨了聚合和聚合根的概念、设计原则以及实际应用。通过结合《领域驱动设计》一书的内容,我们深入理解了聚合和聚合根在构建复杂软件系统中的重要性。通过聚合和聚合根的设计,我们可以构建出高内聚、低耦合的领域模型,确保系统在处理复杂业务逻辑时具有良好的可维护性和扩展性。在实际应用中,我们通过广告业务的示例,展示了如何设计和实现聚合和聚合根,满足具体的业务需求,提高系统的可靠性和可维护性。原创 2024-07-05 09:33:25 · 1019 阅读 · 0 评论 -
7、实体和值对象:领域模型的基础单元
DDD战术设计中有两个重要的概念:实体(Entity)和值对象(Value Object)。二者是领域模型中非常重要的基础领域对象(Domain Object,DO)。从DDD战略设计到战术设计会经历从业务建模到技术落地的多个不同阶段,阶段不同,这些领域对象的形态表现也会不同。在用户旅程分析或场景分析构建领域模型时,实体和值对象是偏业务领域的,主要体现为业务属性和业务行为。原创 2024-07-04 21:35:28 · 781 阅读 · 0 评论 -
6、限界上下文:定义领域边界的利器
为了更好地理解限界上下文,回答上面的问题,我们先从通用语言讲起。在事件风暴过程中,通过团队交流达成共识的,能够简单、清晰、准确地描述业务含义和规则的语言就是通用语言。也就是说,通用语言是团队的统一语言,不管你在团队中担任什么样的角色,在同一个领域的软件生命周期里都使用统一的语言进行交流。那么,通用语言的价值也就很明了了,它可以解决交流障碍的问题,避免因为语言不统一而导致的理解偏差和沟通成本的增加。原创 2024-07-02 21:36:00 · 507 阅读 · 0 评论 -
5、 领域和子域:有效分解问题域
前面提过,在DDD知识体系里有很多概念,比如领域、子域、核心子域、通用子域、支撑子域、限界上下文、聚合、聚合根、实体、值对象、领域服务和应用服务等,它们在DDD理论和知识体系里都是非常重要的概念。从这一章开始,我会围绕上面这些关键概念进行讲解,帮助你彻底理解它们,并理清它们之间的关系,了解它们在微服务设计中的作用。虽然有些名词和概念可能在微服务设计和开发过程中并不一定都用得上,但它可以帮你理解DDD的核心设计思想和理念。而这些设计思想和理念,在IT战略设计、中台领域建模和微服务设计中都是很有价值的。原创 2024-07-01 23:13:45 · 761 阅读 · 0 评论 -
4、DDD、中台和微服务的关系
DDD通过其战略设计和战术设计方法,为中台和微服务的设计提供了有效的指导。通过领域建模和限界上下文的定义,团队可以清晰地划分业务领域的边界,确保服务之间的高内聚和低耦合。同时,领域事件的引入为微服务之间的解耦提供了有效手段,提升了系统的灵活性和可扩展性。通过事件风暴、领域建模和微服务设计,团队可以构建出高效、灵活和可扩展的中台架构,支持企业的数字化转型和业务创新。事件风暴是一种快速构建领域模型的方法。在系统运行过程中,团队需要持续监控和优化微服务架构,确保领域模型和微服务设计的不断演进和优化。原创 2024-07-01 22:27:56 · 1084 阅读 · 0 评论 -
3、微服务设计为什么要选择DDD
然而,随着系统规模和复杂度的增加,集中式架构的缺点也逐渐暴露出来:系统变得臃肿,单一故障点的问题更加突出,扩展性和弹性伸缩能力差等问题依然存在。通过领域建模和限界上下文的定义,团队可以清晰地划分微服务的边界,确保微服务的高内聚和低耦合。DDD在微服务设计中的应用,不仅可以帮助团队划定清晰的业务领域边界,构建合理的领域模型,还能够指导微服务的拆分和设计,确保微服务的高内聚、低耦合。通过本文的学习,我们理解了软件架构的演进历程,微服务设计中的困境,以及DDD在微服务设计中的重要性和具体应用。原创 2024-06-28 09:41:22 · 735 阅读 · 0 评论 -
2、企业中台能力框架
业务中台承载了企业核心关键业务,是企业的核心业务能力,也是企业数字化转型的重点。业务中台的建设目标是:“将可复用的业务能力沉淀到业务中台,实现企业级业务能力复用和各业务板块之间的联通和协同,确保关键业务链路的稳定高效,提升业务创新效能。数据中台与业务中台互为依存,数据中台的大部分数据来源于业务中台,数据中台完成数据加工后为业务中台提供数据服务,实现业务数据化和数据业务化的目标。通过业务能力、数据能力、技术能力和组织能力的综合提升,企业能够构建一个高效、灵活和可扩展的中台体系,支持企业业务的快速发展和创新。原创 2024-06-27 09:29:43 · 826 阅读 · 0 评论 -
1、数字化中台初步认识与建设策略
中台的本质是对企业各个业务板块的共同需求进行业务和系统的抽象,形成通用的、可复用的业务模型,并将其打造成组件化产品供前台使用。通过这种方式,前台业务可以更敏捷、快速地响应市场变化。传统企业在实施中台战略时,需要根据自身的业务特点和现状,制定适合自己的中台建设策略。通过分步骤实施、技术选型和架构设计、团队建设和管理、监控和反馈等措施,确保中台建设能够真正满足业务需求,支持企业的发展。在中台建设过程中,还需要注重前台、中台和后台的协同和融合。原创 2024-06-27 09:15:35 · 789 阅读 · 0 评论