浅析 DDD 领域驱动设计，美团优选java面试

- 持久层： 提供数据查询和存储服务，包括按照状态查询信用卡。

四层架构：

• 表现层： 同三层架构表现层。

• 应用层： 定义软件要完成的任务，不包含业务逻辑，而是协调，比如受理用户请求的任务。负责非

业务逻辑（批量删除、修改等）

• 领域层： 同三层架构领域层。

• 基础层： 为各层提供通用的技术能力。为领域层提供数据和文件存储。

分层架构最重要的是每一层关注自己的职责，持久层只负责提供查询、更新和存储数据的服务，和业务逻辑无关的，所以持久层提供按照还款状态查询信用卡的服务，这样做的好处增加复用性，后续领域层提供展示已还款的信用卡服务时能复用持久层的查询服务。

分层架构的好处

分层架构的目的是通过关注点分离来降低系统的复杂度，同时满足单一职责、高内聚、低耦合、提高可复用性和降低维护成本。

单一职责：每一层只负责一个职责，职责边界清晰，如持久层只负责数据查询和存储，领域层只负

责处理业务逻辑。

高内聚： 分层是把相同的职责放在同一个层中，所有业务逻辑内聚在领域层。这样做有什么好处呢？试想一下假如业务逻辑分散在每一层，修改功能需要去各层修改，测试业务逻辑需要测试所有层的代码，这样增加了整个软件的复杂度和测试难度。

低耦合： 依赖关系非常简单，上层只能依赖于下层，没有循环依赖。

可复用： 某项能力可以复用给多个业务流程。比如持久层提供按照还款状态查询信用卡的服务，既可以给申请信用卡做判断使用，也可以给展示未还款信用卡使用。

易维护： 面对变更容易修改。把所有对外接口都放在对外接口层，一旦外部依赖的接口被修改，只需要改这个层的代码即可。

以上这些既是分层的好处也是分层的原则，大家在分层时需要遵循以上原则，不恰当的分层会违背了分层架构的初衷。

分层架构的缺点

分层架构也有几个缺点

开发成本高： 因为多层分别承担各自的职责，增加功能需要在多个层增加代码，这样难免会增加开发成本。但是合理的能力抽象可以提高了复用性，又能降低开发成本。

性能略低： 业务流需要经过多层代码的处理，性能会有所消耗。

可扩展性低： 因为上下层之间存在耦合度，所有有些功能变化可能涉及到多层的修改。

六、领域模型(domain model)

---

领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、业务对象模型、领域对象模型、分析对象模型。

它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

优点是系统层次结构清楚，各层之间单向依赖， Client -> (Business Facade) -> Business Logic -> Data Access Object 可见，领域对象几乎只做传输介质的用处，不会影响到层次的划分。

领域对象只是作为保存状态或者传递状态使用，它是没有生命的，只是数据没有行为的对象不是真正的对象。

七、贫血模型

---

贫血模型是指领域对象里只有 get 和 set 方法（一般是指POJO）,所有的业务逻辑是不包含在这里面的而是放在 Business Logic层。

在使用Spring的时候，通常就暗示着我们使用的是贫血模型，我们把Domain类用来单纯地储存数据，Spring管不着这些类的注入和管理，Spring关心的逻辑层（比如单例的被池化了的Business Logic层） 可以被设计成Singleton的Bean。

假设我们这里改变一下，就在Domain类中提供业务逻辑方法，那么我们在使用Spring构造这样的数据Bean的时候会遇到很多麻烦，比如 Bean之间的引用，可能引起大范围的Bean之间的潜逃构造器的调用。

八、充血模型

---

大多业务逻辑和持久化放在Domain Object 里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成 Client -> (Business Facade) -> Business Logic -> Domain Object -> Data Access Object。

优点：

是面向对象，Business Logic 符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。

缺点

如何划分业务逻辑，什么样的逻辑应该放在 Domain Object中，什么样的业务逻辑应该放在Business Logic中，其实是比较模糊的。

即使划分好了业务逻辑，由于分散在Business Logic和Domain Object层中，不能更好的划分模块开发。

熟悉业务逻辑的开发人员需要渗透到Domain Logic中去，而在Domain Logic又包含了持久化，对于开发者者这是十分混乱的。

如果Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在Domain logic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。

使用RoR开发时，每一个领域模型对象都可以具备自己的基础业务方法，通常满足充血模型的开发，充血模型更适合复杂业务逻辑的设计开发。

充血模型的层次和模块的划分是一门学问，对开发人员要求也比较高，可以考虑定义这样的一些规则：

（1） 事务控制不要放在领取模型的对象中实现，可以放在facade中完成。

（2） 领域模型对象中只保留该模型驱动的一般方法，对于业务特征明显的特异场景方法调用放在facade中完成。

九、传统的数据驱动开发模式

---

View、Service、Dao 这种三层模式，开发者会很自然的写出过程式代码，这种开发方式中的对象只是数据载体，而没有行为，是一种贫血对象模型，以数据为中心，以数据库ER图为设计驱动，分层架构在这种开发模式下可以认为是数据处理和实现的过程。

十、限界上下文(Bounded Context)

---

限界上下文：定义了每个模型的应用范围

一个业务领域可以划分成多个BC，它们之间通过Context Map进行集成。BC是一个显式的边界，领域模型Bianc便存在于这个边界之内。领域模型是关于某个特定业务员领域的软件模型，通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。

关于限界上下文，有一个很形象的类别，细胞和细胞膜的类比：

细胞之所以能存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，而且确认了什么物质可以通过细胞膜

BC可以类比为细胞膜，大型系统由于其复杂性，对于一个对象如果采取统一建模方式，可能会产生不可预测的效果。例如书中提到的客户发票中的收费对象故障，其实类似问题也在很多地方可以看到。

十一、什么是 CQRS？

---

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

最后总结我的面试经验

2021年的金三银四一眨眼就到了，对于很多人来说是跳槽的好机会，大厂面试远没有我们想的那么困难，摆好心态，做好准备，你也可以的。

另外，面试中遇到不会的问题不妨尝试讲讲自己的思路，因为有些问题不是考察我们的编程能力，而是逻辑思维表达能力；最后平时要进行自我分析与评价，做好职业规划，不断摸索，提高自己的编程能力和抽象思维能力。

BAT面试经验

实战系列：Spring全家桶+Redis等

其他相关的电子书：源码+调优

面试真题：

[外链图片转存中…(img-Ww8aIBhM-1711177097002)]

BAT面试经验

实战系列：Spring全家桶+Redis等

[外链图片转存中…(img-VDVPb2Hy-1711177097003)]

其他相关的电子书：源码+调优

[外链图片转存中…(img-ftp7Yfjh-1711177097003)]

面试真题：

[外链图片转存中…(img-yf5Kcdte-1711177097004)]

[外链图片转存中…(img-GvkYMVUX-1711177097004)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录