1. 杂：
1. Spring Boot的Shutdown Hook让你在应用关闭时进行必要的资源清理，帮助你保证应用在关闭时不会留下潜在的资源泄漏或不一致状态。在上线的时候，通过这个可以优雅发布，避免一些不必要的损失。
2.线程池，其实是支持动态配置的，所以可以做个平台管理和监控。
3.发布服务的时候，怎么做到尽量不丢请求。比如mq、线程池里面的任务、rpc调用。这叫平滑发布。
4.Sdd+ddd，限界上下文，领域内自治。分治法是应对复杂度的唯一办法。但是sdd文档要少，最好一个。
5. DDD application service 和 domain service区别一句话总结：应用服务负责“把事办成”（跑腿、打电话、搬东西）；领域服务负责“把事办对”（定规矩、做计算、做决策）。
6. Domain Service：故事的“高潮/核心情节”。Application Service：故事的“导演/旁白”。
7. DDD 最难的不是初创时的分层，而是在长期的业务迭代中对抗“破窗效应”。
8. 当后续开发者不理解“导演”和“编剧”的区别时，系统就会迅速退化为贫血模型。要守住“故事情节”，不能光靠开发者的自觉，得靠规则、工具和结构。
9.“不提供 Setter”是 DDD 落地最简单的硬手段。它就像是给核心剧本加了“只读锁”，任何人想要改动情节，必须通过你预留的“接口（业务方法）”。这不仅是保护了代码，更是通过代码强迫后续开发者去思考业务语义。如果有人问起，你就告诉他：“这里没有字段，只有业务。”
11. spring retry
12. 扩大对设计能力的投资，降低对语言和框架的投资。
2. 关于领域：
1.领域就是用来确定范围的，范围即边界，这也是DDD在设计中不断强调边界的原因。DDD的领域就是这个边界内要解决的业务问题域。
2. 领域可以细分为子域，各个子域都会有自己的知识体系，也就是DDD的领域模型，所有子域加起来就建立了领域的知识体系。
3.在DDD（领域驱动设计）中，核心域、通用域、支撑域统称为“子域”，它们的划分是为了帮助团队根据业务价值来分配有限的资源。
4. 子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。
5. 核心竞争力的子域属于核心域；没有太多个性化需求，同时被多个子域使用的属于通用域；不核心、不通用就属于支撑域，支撑域是为了让核心业务跑起来的辅助功能，不可或缺，但是不具备核心竞争力。例如：电商系统里的数据报表、物流系统里的地址管理。
6. 核心域最重要，要放到首位。通用域可以买。支撑域能用就行。
7. 其实到创业上也是一样的，要搞明白什么是自己的“核心域””，把有限的资源投入到其中。重仓核心域。
8.你的核心域到底在哪？我们可以用一个简单的标准来判断：“如果把这一块抽掉，你的平台还值钱吗？
3. 限界上下文：
1.通用语言定义上下文含义，限界上下文则定义领域边界。
2.语言离不开它的语义环境。而业务的通用语言就有它的业务边界，我们不大可能用一个简单的术语没有歧义地去描述一个复杂的业务领域。限界上下文就是用来细分领域，从而定义通用语言所在的边界。通过领域的限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流。
3.正如电商领域的商品一样，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。看到这，我想你应该非常清楚了，领域边界就是通过限界上下文来定义的。
4. 领域模型中，如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。
5. 每个领域模型都有它对应的限界上下文，团队在限界上下文内用通用语言交流。
6. 限界上下文，归根结底还是为了降低认知负荷。
4. 实体和值对象：
1. 在DDD里，实体类通常采用充血模型，与实体相关的所有业务逻辑都在实体类的方法中实现，跨多个实体的领域逻辑则在领域服务中实现。
2. 值对象创建后就不允许修改了，只能用另外一个值对象来整体替换。
3. 值对象就是通过这种方式，简化了数据库设计，总结一下就是：在领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量；在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。JSON字段。
4. 最低层都是值对象”是正确的，它揭示了信息表示的终极本质。然而，DDD通过引入*“身份”这一核心概念，在“值”的基础之上，构建了具有不同语义和行为特征的实体和值对象*。“值”是构建材料，而“身份”是赋予实体生命和意义的灵魂。
5. 抽象出值对象的核心意义在于：1从“数据”到“领域概念”：提升代码的语义层次。值对象本质上就是一个集，保证属性归类的清晰和概念的完整性，避免属性零碎。
5. 聚合和聚合根
1. 领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。
2. 聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。
3. 聚合根是聚合的管理者，是聚合对外的接口人，也就是说外部访问都要通过聚合根。说白了聚合根就是leader。
4. 聚合不要设计太大，复杂且性能低。
5. 聚合内强一致性，聚合外最终一致性。如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的方式异步修改相关的聚合，实现聚合之间的解耦。
6. 一个聚合只有一个聚合根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过ID关联的方式实现聚合之间的协同。
6. 领域事件
1.领域事件，最终一致性，为什么不直接调用？因为一次事务只处理一个聚合的状态，如果一个业务要涉及多个聚合的状态的更改，就应该采用领域事件的最终一致性。
2. 领域事件驱动设计可以切断领域模型之间的强依赖关系。
3. 微服务内应用服务，可以通过跨聚合的服务编排和组合，以服务调用的方式完成跨聚合的访问，这种方式通常应用于实时性和数据一致性要求高的场景。
4. 事件发布之前需要先构建事件实体并持久化。事件发布的方式有很多种，你可以通过应用服务或者领域服务发布到事件总线或者消息中间件，也可以从事件表中利用定时程序或数据库日志捕获技术获取增量事件数据，发布到消息中间件。
5. 领域事件驱动机制可以实现一个发布方N个订阅方的模式，这在传统的直接服务调用设计中基本是不可能做到的。
6. 关于数据库的小技巧：INSERT IGNORE INTO。当插入的数据与表中已有记录的主键或唯一键冲突时，忽略该条记录的插入操作，而不是报错。
7. DDD分层架构
1. 上下文环境层，可以简单理解为是和别的服务通信的外交官。由这一层处理字段命名的差异等。
2. 基础层是贯穿所有层的，依赖倒置，高层模块不再卑微地适配底层，而是底层去适配高层定义的协议。谁定义接口谁是大爷。
3. 通常大家认为阿里的中台对应DDD的通用域，将通用的公共能力沉淀中台，对外提供通用共享服务。中台这个概念基本上已经G了，中台对应的不是云服务器等基础设施，对应的是业务逻辑，会失败。技术中台（如中间件、容器化、数据库） 是神药，必须搞。数据中台（如报表、用户画像）是好药，可以搞。业务中台（如订单中心、会员中心）是毒药，千万别迷信。别学阿里，学亚马逊。
4.DDD分层架构、整洁架构、六边形架构都是以领域模型为核心，实行分层架构，内部核心业务逻辑与外部应用、资源隔离。
