《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！
- 严格分层架构(Strict Layers Architecture)
某层只能与其直接下层耦合，即我的奴隶的奴隶，不是我的奴隶。
- 松散分层架构(Relaxed Layers Architecture)
允许任意上层与任意下层耦合。由于用户接口层和应用服务通常需要与基础设施打交道，许多系统都是该架构。
较低层有时也可与较高层耦合，但只限于采用观察者 (Observer)模式或者调停者(Mediator)模式场景。
较低层绝不能直接访问较高层。例如，在使用调停者模式时，较高层可能实现了较低层的接口，然后将实现对象作为参数传递到较低层。当较低层调用该实现时， 它并不知道实现出自何处。
1.3.1 传统四层架构
将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层逻辑的依赖，因为它们不属业务逻辑。将一个夏杂的系统分为不同的层，每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。
传统分层架构的基础设施层位于底层，持久化和消息机制便位于该层。
这里的消息包含
-
MQ消息
-
SMTP
-
文本消息(SMS)
可将基础设施层中所有组件看作应用程序的低层服务，较高层与该层发生耦合以复用技术基础设施。即便如此，依然应避免核心的领域模型对象与基础设施层直接耦合。
1.3.2 改良版四层架构
传统架构的缺陷
DDD初创开发团队发现，将基础设施层放在最底层存在缺点，比如此时领域层中的一些技术实现就很困难：
-
违背分层架构的基本原则
-
难以编写测试用例
何解？
使用依赖反转设计原则：低层服务（如基础设施层）应依赖高层组件（比如用户界面层、应用层和领域层）所提供的接口。
应用依赖反转原则
- 依赖反转原则后的分层方式：基础设施层在最上方，可实现所有其他层中定义的接口
依赖反转原则真的可以支持所有层吗？
有人认为依赖反转原则中只存在两层：最上方和最下方，上层实现下层定义的抽象接口。因此上图的基础设施层将位于最上方，而用户接口层、应用层和领域层应作同层且都位于下方。对此大家可保留自己意见。
=====================================================================
一般包括用户接口、Web 服务等。
只处理用户显示和用户请求，不应包含领域或业务逻辑。
有人认为，既然用户接口需验证用户输入，就无可避免应该包含业务逻辑。事实上，用户接口所进行的验证和对领域模型的验证不同：对那些粗制滥造且只面向领域模型的验证行为，应该予以限制。
如果用户接口使用了领域模型中的对象，那么此时领域对象仅限于数据渲染展现。在采用这种方式时，可使用展现模型对用户接口与领域对象进行解耦。
由于用户可能是人，也可能是其他系统，有时用户接口层将采用开放主机服务的方式向外提供API。
用户接口层是应用层的直接用户。
用户接口层在于前后端调用的适配。若你的微服务要提供服务给很多外部应用，而对每个外部应用的入参出参都不同，你不可能开发一堆一对一的应用服务，这时Facade接口就起到了很好的作用，包括DO和DTO对象的组装和转换。
由于主要负责接入各种终端，所以该层有人也叫接入层。
实际开发中，我们都会感受到该层依附于应用层存在。随前后端分离，Restful API 流行，对简单的系统来说该层越来越弱化。对于有终端接入的系统来说，该层并不简单，需要处理各种协议适配：XMPP、websocket、MQTT 等。
复杂度不高时，我们往往把该层和应用层合并部署，主要凭开发经验和理解程度来决定。
存放用户接口层与前端交互、展现数据相关的代码。
前端应用通过这层接口，向应用服务获取展现所需的数据。
该层主要用来处理用户发送的Restful请求，解析用户输入的配置文件，并将数据传递给应用层。
数据的组装、数据传输格式以及Facade接口等代码都会放在这一层目录里。
封装应用服务和对外暴露接口。
特点
-
关心视图和对外的服务，Restful、页面渲染、websocket、XMPP 连接等
-
如果没有多种用户端接入方式，可以和应用层合并
-
对应到分布式系统中的网关、BFF、前台等概念
-
只产生接入异常，例如数据校验，对应 HTTP 状态码 400、415 等
-
一个应用可以有多个接入层
-
接入层做和业务规则无关的 bean validation 验证
-
准单体系统下，按照连接方式分包
该层指的是服务端用于适配端侧的部分，而非端侧本身。因为该层本就依赖应用层，无人使用接口在这里做依赖倒置，所有又被称作主动适配。
- assembler、dto 和 façade
facade
提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。比如调用应用层创建用户的方法。
dto
数据传输的载体，内部不存在任何业务逻辑，可以通过DTO把内部的领域对象与外界隔离。
比如接收请求传入的数据CustomerDTO。
不同的对象在不同的层转换。用户接口层DTO和DO转换，应用层主要是DO，调外部微服务的服务的时候应用层有dto和do的转换。领域层与基础层之间，在基础层有DO和PO的转换。
在接口层定义DTO对象。数据可能来源于多个DO对象。
assembler
实现DTO与DO间的相互转换和数据交换。
一般assembler与dto一同出现。比如创建用户时，将CustomerDTO转换为CustomerEntity。你可以在用户接口层创建DTO类和assembler类。在assembler类里完成映射。
特点
-
关心处理完一个完整的业务
-
该层只负责业务编排，对象转换，实际业务逻辑由领域层完成
-
不关心【请求从何处来】，但是关心【谁来、做什么、有没有权限做】
即复制安全认证、权限校验
- 集成不同的领域服务解决问题
应用层位于领域层之上，因为领域层包含多个聚合，所以它可协调多个聚合服务和领域对象完成服务编排和组合，协作完成业务。
-
最终一致性（最终一致性对业务有侵入）事务放到这层
-
对应到分布式系统中的中台等概念
-
方法级别的功能权限控制放到这层
-
只产应用异常，对应 HTTP 状态码 403、401
-
准单体系统下，按照应用划分模块
主要包含应用服务，理论上不应有业务规则或逻辑，而主要是面向用例和流程相关的操作。
- 应用层也是微服务间的交互通道，它可调用其它微服务，完成微服务间的服务组合和编排。
开发设计时，不要将本该放在领域层的业务逻辑放到应用层。庞大的应用层会使领域模型失焦，时间一长，微服务就会退化为MVC。
应用服务是在应用层，负责
-
服务的组合、编排、转发、转换和传递，处理业务用例的执行顺序以及结果的拼装，以粗粒度服务通过API网关发布到前端
-
发送或订阅领域事件
应用层代码目录结构
存放应用层服务组合和编排相关的代码。
应用服务向下基于
-
微服务内的领域服务，或
-
外部微服务的应用服务
完成服务的编排和组合
向上为用户接口层提供各种应用数据展现支持服务。
应用服务和事件等代码会放在这层目录。
Event（事件）
主要存放事件相关代码。包括两子目录：
publish
主要存放事件发布相关代码。比如发布用户创建事件给其它微服务。
subscribe
主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）。
虽然应用层和领域层都可进行事件的发布和处理，但为实现事件的统一管理，推荐将微服务内所有事件的发布和订阅处理都统一放到应用层，事件相关的核心业务逻辑实现放在领域层。通过应用层调用领域层服务，来实现完整的事件发布和订阅处理流程。
Service（应用服务）
应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。
可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。
比如内部服务->创建用户；外部服务->创建日志。
主要包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
实现核心业务逻辑，通过各种校验保证业务正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
领域模型的业务逻辑主要由实体和领域服务实现：
- 实体采用充血模型 实现所有与之相关的业务功能。
实体和领域服务在实现业务逻辑上不是同级，当领域中的某些功能，单一实体或值对象无法实现，就会用到领域服务，它可组合聚合内的多个实体或值对象，实现复杂业务逻辑。
============================================================================
存放领域层核心业务逻辑相关的代码。
可包含多个聚合代码包，共同实现领域模型的核心业务逻辑。聚合以聚合内的实体、方法、领域服务和事件等代码会放在该层目录。
领域层包括一个或多个聚合的实体类、事件实体类、领域服务以及工厂、仓储相关代码。一个聚合对应一个聚合代码目录，聚合之间在代码上完全隔离，聚合之间通过应用层协调。
Domain 由一或多个聚合包构成，共同实现领域模型的核心业务逻辑。
聚合内的代码模型是标准和统一的，包括：entity、event、repository、service 子目录
聚合软件包的根目录，可根据实际项目的聚合名称命名，比如权限聚合。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。聚合内实现高内聚的业务逻辑，它的代码可以独立拆分为微服务。
以聚合为单位的代码放在一个包里的主要是为业务内聚，更是为以后微服务之间聚合的重组。聚合之间清晰的代码边界，可让你轻松地实现以聚合为单位的微服务重组。
实例
比如进入用户聚合目录下(如CustomerAggregate)。
假设这样一个场景，主播账户作为一个聚合，优惠券模块作为一个聚合。那主播选券的命令属于主播账户聚合。然后主播账户里的优惠券就是这个聚合里的值对象。
如果有多个聚合， 比如聚合根A和聚合根B， 从业务的角度讲，可以接受AB间数据的最终一致性，但从数据展示的角度考虑， A和B是有强关联性的，也就是说在页面上，他们总是一起在页面的某部分出现， 那可以分别调两个聚合的领域服务，然后将两个聚合根的DO对象转换为一个DTO，就可以给前端提供包含两个聚合数据的数据服务了。
细分结构
Entity（实体）
存放聚合根、实体、值对象以及工厂模式（Factory，工厂模式主要是实现复杂聚合的实体的数据初始化。如果实体太多，聚合根处理起来会很复杂，通过工厂一次初始化）相关代码。实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。比如用户聚合根。
Event（事件）
存放事件实体以及与事件活动相关的业务逻辑代码。比如创建用户的事件。
Service（领域服务）
存放领域服务代码。一个领域服务是多个实体组合出来的一段业务逻辑。你可以将聚合内所有领域服务都放在一个领域服务类中，你也可以把每一个领域服务设计为一个类。如果领域服务内的业务逻辑相对复杂，我建议你将一个领域服务设计为一个领域服务类，避免由于所有领域服务代码都放在一个领域服务类中，而出现代码臃肿的问题。领域服务封装多个实体或方法后向上层提供应用服务调用。比如具体的创建用户逻辑，比如用户是否重复校验，分配初始密码等。
Repository（仓储）
存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，设定原则：一个聚合对应一个仓储。比如将用户信息保存到数据库。
按DDD分层架构，仓储实现本应属基础层代码，但为在微服务架构演进时，保证代码拆分和重组的便利性，把聚合仓储实现的代码放到聚合包内。这样，如果需求或设计发生变化导致聚合需要拆分或重组，就可将包括核心业务逻辑和仓储代码的聚合包整体迁移，轻松实现微服务架构演进。
为其它各层提供通用技术基础服务：
-
三方工具
-
驱动
-
MQ
-
API网关
-
文件
-
缓存
-
DB
最常用的
基础层包含基础服务，它采用依赖反转，封装基础资源服务，实现应用层、领域层与基础层解耦。
MVC架构由于上层应用对DB强耦合，很多公司在架构演进最怕换DB，一旦更换，可能需重写一堆代码。
但采用依赖反转，应用层即可通过解耦保持独立核心业务逻辑。当DB变更，只需更换DB基础服务。
====================================================================================
主要存放基础资源服务相关的代码，为其它各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层目录里。
Infrastructure 的代码目录结构有：config 和 util 两个子目录。
- Config
主要存放配置相关代码。
- Util
存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录。
最后
码字不易，觉得有帮助的可以帮忙点个赞，让更多有需要的人看到
又是一年求职季，在这里，我为各位准备了一套Java程序员精选高频面试笔试真题，来帮助大家攻下BAT的offer，题目范围从初级的Java基础到高级的分布式架构等等一系列的面试题和答案，用于给大家作为参考
以下是部分内容截图
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！
e_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_1,color_FFFFFF,t_70)
- Config
主要存放配置相关代码。
- Util
存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录。
最后
码字不易，觉得有帮助的可以帮忙点个赞，让更多有需要的人看到
又是一年求职季，在这里，我为各位准备了一套Java程序员精选高频面试笔试真题，来帮助大家攻下BAT的offer，题目范围从初级的Java基础到高级的分布式架构等等一系列的面试题和答案，用于给大家作为参考
以下是部分内容截图
[外链图片转存中…(img-LuyjQFAD-1714471509711)]
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！
2870
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
