解决一个业务场景中的复杂问题从理解问题域开始，通过专注于问题域并理解复杂问题背后的实质，你才能设计有效的模型来应对业务的挑战。在项目初期，尽量避免沉溺于技术实现，而要把焦点集中在问题领域，不要忘记技术服务业务的原则。
理解问题域
我们以一个金融场景下的“业务运营监控系统”为例进行分析。
经过与运营管理专家和相关业务方的多轮需求探论，我们初步了解了用户的业务诉求和痛点。需要强调的是对于问题域的充分理解是我们的首要任务。
这里整理了一份需求文档，它详细地记录了问题域的具体范围和详细需求。这份文档不仅是业务与技术团队之间的一份沟通文档，也可以作为软件生命周期在需求分析阶段的一个清晰的、规范化的知识协作产物。
提炼问题域
理解复杂问题并从中识别、提炼出关键的业务模型，即提炼问题域是领域驱动设计的关键环节。团队可以通过头脑风暴的形式罗列出领域中的所有事件，整合之后形成最终的领域事件集合。
你需要在关键事件标记的范围里，参照不同利益干系方的业务诉求，组织领域事件和模型，同时，你需要整理出与项目关联的上下游系统，如下图所示。
通过挖掘隐藏在领域事件中的核心领域模型，我们可以找到从问题空间到方案空间的对应映射关系。针对上述业务监控系统案例，“进件存量”和“进件流量”的概念成为我们发现的重要领域模型。
作为衡量业务系统运转状态的重要指标，业务的“存量”状态可以表示业务的积压情况，而业务的“流量”状态可以表示业务流转的变化情况。
如下图所示是我们总结的监控系统概要视图，其中实线表示的是城市信贷业务工作流中进件在不同系统的流向，而虚线表示的则是业务的存量、流量在业务监控系统的事件记录。
服务的拆分
=====
完成问题域的理解和提炼后，我们需要对整体系统做进一步的服务拆分。下图是我们根据业务领域能力对“业务运营监控系统”进行拆分后的子领域服务及模块划分说明。
● 业务事件收集（如下图和表所示）
● 事件过滤聚合（如下图和表所示）
● 规则配置（如下图和表所示）
● 监控查询展示（如下图和表所示）
为什么要做服务拆分
● 降低系统的整体复杂性：根据业务领域进行合理的服务拆分是一个有效控制系统复杂性的方法。
● 提高效率：服务拆分后，代码模块相互隔离，并发的开发模式可以提升开发人员的效率。
● 团队人员各司其职：拆分的项目可分派给擅长相关方面技术的人员，让团队成员各司其职，降低工作的耦合度。
● 共享和自治：可以通过定义好的服务接口进行服务共享，同时拆分后的服务也更加自治。
● 解决依赖问题：通过服务拆分，可以清晰地了解哪些服务依赖会对业务造成影响，从而准备预案。
服务拆分的依据
高内聚、低耦合是服务拆分的主要依据，下面我们列举一些常用的服务拆分策略，了解如何对单体架构进行拆分。
● 区分服务类型：工具服务区别于业务服务，它的特点是与业务领域无关，根据其用途可以进一步细分，一般包括的形式有公共工具服务、资源工具服务、包装器服务等。
● 根据功能定义划分服务：领域驱动设计通过分析问题空间和业务逻辑，将应用程序定义为域，域由多个子域组成，每个子域对应于业务的不同功能部分。
● 根据技术边界划分服务：对于产品类型的服务使用技术能力划分服务边界，前后端分离架构就是通过技术栈划分服务边界的典型架构模式。
服务拆分范式
通过增加服务实例或者机器来解决服务的容量和可用性问题是常用的可扩展架构解决方案。在《可扩展艺术》一书中提出了系统的可扩展性模型：AKF可扩展立方，可以作为服务拆分的范式。
如下图所示是使用Scale Cube的3D模型实现的一个微服务架构模型，在X轴上通过API网关进行水平扩展，在Y轴上进行单体拆分后的微服务构建，服务之间可以通过REST API进行简单交互，Z轴是数据维度的拆分。
● X轴：服务扩展，通过克隆的方式水平扩展。一般是负载均衡后运行多个应用副本，达到某个服务的高吞吐量和高可用性。
● Y轴：功能拆分，通过拆分不同的事务进行扩展。微服务对应着Y轴，即将单体应用拆分为微服务应用。
● Z轴：数据分区，通过分隔相同的事务进行扩展，例如数据库分库分表。
总之，服务支持水平扩展以提升容量；对功能的拆分体现在对业务模型的切入和深入理解上；应用数据的划分是微服务的重要原则，如果数据的耦合问题无法解决，那么应用服务的划分还会有代码耦合和级联影响。
界限上下文
=====
在找到服务边界并把系统拆分后，我们需要使用“界限上下文”的概念明确服务之间的交互共享模型和行为接口，它不仅可以有效地限定领域的职责边界和特性范围，也可以控制问题域的规模，进而以化整为零的方式控制整个系统的复杂性。
在业务运营监控项目中，存量项模型作为业务过滤聚合服务和存量查询统计服务的共享模型，关系如下图所示。
为了实现捕获和统计监控业务运营过程中的不同阶段存量的业务状态，我们将存量项作为上述两个服务上下文的共享模型，但我们不会暴露“过滤聚合服务”中的存量明细、Flow、Stream等模块的实现细节。
作为两个独立的服务主体，它们应该在边界上有明确的界线划分和通信机制。如果服务边界与领域的界限上下文能够保持一致，那么我们已经为高内聚、低耦合的微服务架构实现了关键的一步。
领域建模
====
领域建模是领域驱动设计的核心，通过领域模型可以封装对业务的抽象，建立业务概念与领域规则的关系。领域模型更关注的是业务语义的显性表达，而不是具体的数据存储及代码逻辑实现细节，它可以有效地降低业务人员和技术人员之间的沟通成本。
案例分析
回到“业务运营监控系统”中，我们把业务监控的核心诉求聚焦在“业务事件”，以及业务的存量和流量领域模型。在整理了领域服务的核心模块后，我们可以把业务方关注的组织信息、业务类型信息、业务阶段信息进行进一步领域模型细化，如下图所示。
● BizEvent：业务事件是业务监控的数据源，使用统一的JSON格式记录消息事件，以日志方式封装当前业务系统发生的事件详情。
● Stream：对应一个端到端的数据流转概念，通常我们会将BizEvent事件发送到Kafka的一个Topic上，通过建立Stream可以在消费端处理指定Topic上的数据流。
● Flow：Flow对应一个监控业务计算逻辑，存量Flow可以统计对应的存量状态，流量Flow统计当前业务的流量状态。
● Service：它并非领域对象，表示一个通用的服务层，Service提供业务存量和流量的查询、备份、预警等业务方法。
● Provision：用户配置前置通用服务，不对应领域对象，主要接收用户的配置请求，并保存为业务规则。
● Rule：即规则模型，属于核心领域模型，业务方可以通过它灵活地定制关心的业务状态并进行预警、过滤等。
● Detail：属于业务的中间监控过程详情，属于领域对象，同时包含组织、阶段、业务类型等明细对象属性（Org、Phase、BizType）。
使用领域建模的设计方法可以进一步将“业务监控系统”内部的领域服务与领域模型对象关联，显性地表达每个领域模型的具体工作职责及业务行为事件与领域对象之间的上下文映射关系，如下图所示。
架构设计
====
架构设计的本质是管理业务和技术复杂性，使系统易于有序化重构及扩展。高质量的架构一定是高度抽象的、围绕业务的、易于理解的、面向演进的。
分层架构设计
领域驱动设计遵循“关注点分离”原则，将技术实现逻辑封装在基础设施层；将业务逻辑封装在领域层，尽量使领域层代码与其他层技术细节分割开来；将应用层作为黏合剂，实现前两者的协作；同时UI层可以基于Swagger技术暴露REST API。分层架构如下图所示。
六边形（Hexagonal）架构模式
六边形架构模式又称为“端口-适配器”模式，它将系统分为内部和外部。内部代表应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。内部以API接口呈现，通过端口和外部系统通信。外部系统需要使用不同的适配器，适配器负责对协议进行转换。应用程序能够以一致的方式与实际运行的设备和数据库相隔离，方便开发和测试，六边形架构模式如下图所示。
微服务架构模式
微服务架构是强调细粒度、单一职责的架构模式。微服务架构更关注的是系统的非功能需求：质量属性、演进能力、扩展性、观测性、软件交付效率等。微服务使用CQRS（命令/查询职责分离）中的事务脚本模式应对查询场景，而对于复杂的业务逻辑场景，使用领域驱动设计模式。微服务架构模式如下图所示。
最后
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Java开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！
如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
866543982)]
[外链图片转存中…(img-wqP5RV5v-1715866543982)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Java开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！
如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
378
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
