本文介绍了Java工程师面试中常见的技术点，如MyBatis、ZooKeeper等，并探讨了领域驱动设计在软件开发中的重要性，包括理解业务复杂性、技术复杂性，以及如何通过事务脚本模式和领域建模模式来简化问题。文章还详细讲解了领域驱动设计的核心要素和在实际项目中的应用，如服务拆分策略，以降低复杂性和提高开发效率。
最后
面试题文档来啦，内容很多，485页！
由于笔记的内容太多，没办法全部展示出来，下面只截取部分内容展示。
1111道Java工程师必问面试题
MyBatis 27题 + ZooKeeper 25题 + Dubbo 30题：
Elasticsearch 24 题 +Memcached + Redis 40题：
Spring 26 题+ 微服务 27题+ Linux 45题：
Java面试题合集：
领域驱动设计在战略设计层面，从业务视角出发使技术人员专注于问题域，从领域专家那里获得领域见解，通过模块划分建立领域服务边界，通过界限上下文明确服务的职责。领域驱动设计在战术设计层面，从技术的视角出发，提炼有效的业务模型，实施领域建模、架构设计完成软件的落地。领域驱动设计通过隔离业务与技术的复杂性，成为程式化、标准化的软件架构设计范式。
软件复杂度的来源
● 业务的复杂性：业务的复杂性体现在业务流程不清晰、业务参与人员多、业务与技术耦合等方面。在业务的早期阶段，为了快速满足功能需求容易形成面条式的代码风格，这样的代码风格会导致软件模块膨胀、开发效率降低、功能扩展步伐放缓、业务模型与代码脱节等。
● 技术的复杂性：技术的复杂性来源于对项目的质量属性需求，诸如系统的性能、客户体验、服务高可用性等。为解决服务的响应延迟、吞吐、安全等问题，我们会引入缓存、消息队列、第三方模块组件，而这些技术的整合给系统引入了额外的复杂性和技术挑战。
领域驱动解决之道
解决这种软件构建中面临的复杂性问题，我们需要从领域开始着手，与业务专家一起获得领域见解，促使软件利益干系方在领域内建立通用语言。技术人员通过建模的手段提炼出事物的本质，以便更好地指导应用系统的构建和规划。
领域驱动设计中包含了大量成熟的理论、概念、模式和架构，它包含一套解决复杂领域模型的软件架构方法，思想是围绕业务模型来连接和实现核心业务概念。
领域驱动设计可以让业务和技术的变化产生的不可预知因素互相分离，将人员变动、团队规模、协作沟通等外界因素变化对产品和项目的影响封装在一个可控的容器和框架下，从而解决软件面临的复杂性问题，如下图所示。
事务脚本模式与领域建模模式
● 事务脚本模式：事物脚本模式常见于单体应用中，它将所有逻辑全部组织在一个单一过程方法中，从数据库的调用到不同业务逻辑、策略的执行全部集成在一个大的方法块中。它的好处是简单、容易实现，它的缺点是没有自己的状态，也无法扩展，容易将服务组件与数据存储模型之间的刚性依赖引入业务逻辑中。
● 领域建模模式：领域建模模式将业务逻辑转移到了领域对象（Domain Object）中，每个领域对象完成属于自己的业务行为。同时数据存储层的逻辑也变得相对简单，数据库不再参与领域模型的业务逻辑，而是回归数据“持久化”的本质。
使用领域模式可以提升系统的内聚性和可重用性，通过不同类之间的协同完成所有功能。另外，多态的模式也让扩展新的策略更加方便，业务语义更加通用、显性化。领域建模过程遵循“SOLID”原则并实现业务域的逻辑解决方案。
说明：SOLID原则
1.Single Responsibility Principle：单一职责原则；
2.Open Closed Principle：开闭原则3.Liskov Substitution Principle：里氏替换原则；
4.Interface Segregation Principle：接口隔离原则；
5.Dependence Inversion Principle：依赖倒置原则；
领域驱动设计核心要素
如下图所示是领域驱动设计的核心要素，包含领域驱动设计中的通用模型术语和重要的战术模式。这些模式不仅可以捕获和传递领域中的概念、关系及逻辑，也能帮助我们管理业务的复杂性并确保领域模型的行为清晰明确。
● 领域：相对于软件系统来说就是系统要解决的现实问题。
● 子域：对于领域进行不同维度切分的相对内聚的子系统单元。
● 分层架构：通过分层架构将业务域和技术逻辑域隔离。
● 服务：服务通常是领域对象的调用方，用来协调领域对象完成指定业务逻辑职责。
● 实体：实体与面向对象中的概念类似，它是领域模型的基本元素，在领域模型中，实体应该具有唯一的标识符。
● 值对象：值对象是没有唯一标识符的实体。值对象在领域模型中是可以被共享的，它们应该是不可变的，当有其他地方需要用到值对象时，可以将它的副本作为参数传递。
● 聚合：聚合使用边界将内部和外部的对象划分开来。每个聚合有一个根，这个根是一个实体作为外部可以访问的唯一对象。
● 资源库：是封装的所有获取对象引用所需的逻辑单元。
● 工厂：工厂用来封装对象创建所必需的信息，当聚合根建立时，所有聚合包含的对象将随之建立。
专注问题域
=====
解决一个业务场景中的复杂问题从理解问题域开始，通过专注于问题域并理解复杂问题背后的实质，你才能设计有效的模型来应对业务的挑战。在项目初期，尽量避免沉溺于技术实现，而要把焦点集中在问题领域，不要忘记技术服务业务的原则。
理解问题域
我们以一个金融场景下的“业务运营监控系统”为例进行分析。
经过与运营管理专家和相关业务方的多轮需求探论，我们初步了解了用户的业务诉求和痛点。需要强调的是对于问题域的充分理解是我们的首要任务。
这里整理了一份需求文档，它详细地记录了问题域的具体范围和详细需求。这份文档不仅是业务与技术团队之间的一份沟通文档，也可以作为软件生命周期在需求分析阶段的一个清晰的、规范化的知识协作产物。
提炼问题域
理解复杂问题并从中识别、提炼出关键的业务模型，即提炼问题域是领域驱动设计的关键环节。团队可以通过头脑风暴的形式罗列出领域中的所有事件，整合之后形成最终的领域事件集合。
你需要在关键事件标记的范围里，参照不同利益干系方的业务诉求，组织领域事件和模型，同时，你需要整理出与项目关联的上下游系统，如下图所示。
通过挖掘隐藏在领域事件中的核心领域模型，我们可以找到从问题空间到方案空间的对应映射关系。针对上述业务监控系统案例，“进件存量”和“进件流量”的概念成为我们发现的重要领域模型。
作为衡量业务系统运转状态的重要指标，业务的“存量”状态可以表示业务的积压情况，而业务的“流量”状态可以表示业务流转的变化情况。
如下图所示是我们总结的监控系统概要视图，其中实线表示的是城市信贷业务工作流中进件在不同系统的流向，而虚线表示的则是业务的存量、流量在业务监控系统的事件记录。
服务的拆分
=====
完成问题域的理解和提炼后，我们需要对整体系统做进一步的服务拆分。下图是我们根据业务领域能力对“业务运营监控系统”进行拆分后的子领域服务及模块划分说明。
● 业务事件收集（如下图和表所示）
● 事件过滤聚合（如下图和表所示）
● 规则配置（如下图和表所示）
● 监控查询展示（如下图和表所示）
为什么要做服务拆分
● 降低系统的整体复杂性：根据业务领域进行合理的服务拆分是一个有效控制系统复杂性的方法。
● 提高效率：服务拆分后，代码模块相互隔离，并发的开发模式可以提升开发人员的效率。
● 团队人员各司其职：拆分的项目可分派给擅长相关方面技术的人员，让团队成员各司其职，降低工作的耦合度。
● 共享和自治：可以通过定义好的服务接口进行服务共享，同时拆分后的服务也更加自治。
● 解决依赖问题：通过服务拆分，可以清晰地了解哪些服务依赖会对业务造成影响，从而准备预案。
服务拆分的依据
高内聚、低耦合是服务拆分的主要依据，下面我们列举一些常用的服务拆分策略，了解如何对单体架构进行拆分。
● 区分服务类型：工具服务区别于业务服务，它的特点是与业务领域无关，根据其用途可以进一步细分，一般包括的形式有公共工具服务、资源工具服务、包装器服务等。
总结
本文从基础到高级再到实战，由浅入深，把MySQL讲的清清楚楚，明明白白，这应该是我目前为止看到过最好的有关MySQL的学习笔记了，我相信如果你把这份笔记认真看完后，无论是工作中碰到的问题还是被面试官问到的问题都能迎刃而解！
MySQL50道高频面试题整理：
白，这应该是我目前为止看到过最好的有关MySQL的学习笔记了，我相信如果你把这份笔记认真看完后，无论是工作中碰到的问题还是被面试官问到的问题都能迎刃而解！
MySQL50道高频面试题整理：
[外链图片转存中…(img-M6fyUnWB-1714925632249)]
147
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
