如果花时间了解一下 DDD 的历史，就会发现 DDD 已经存在了很长时间，单单按照 Eric Evans 成书那一年算起也已经有超过 10 年的历史了。但即使在刚开始的那几年，DDD 也只能说是不温不火，只是小圈子里人们的谈资，鲜少看到分享的文章(至少国内给我的感觉如此)。有意思的是大约三年前开始，DDD 重新回归大众的视野，无论...

许多同学在读了我有关领域驱动设计的文章之后，都会咨询同一个问题，就是具体怎么学习领域驱动设计，有没有什么比较好的学习路径。以我自己的经验而言，其实领域驱动设计并不是什么高深的学问，而编程本身作为一项实践性很强的工作，追求的也是 Show me your code 这种形式。所以在掌握了一定的理论知识之后，结合自己的...

上一篇文章分析了 HashMap 源码中 put 方法的逻辑以及相关哈希算法，处理哈希冲突的部分。我们也看到了 HashMap 内部是使用一个数组来存储元素的。这次我们会分析当元素数量发生变化时，HashMap 是如何管理数组大小的。

上一篇文章中介绍了一些如何在领域驱动设计中使用函数式编程，进而提升代码可用性的技巧。其中缺少了使用函数式编程中 Typeclass(类型类) 的应用场景，恰好最近需要对重构遗留代码中的一个模块(看我拖更的频率就知道这个重构不简单😜)，经过思考之后觉得这项重构可以借助 Monad 提升可维护性，所以稍作整理后便有了这篇文...

这应该是 Java Collections Framework 源码分析的最后一部分了，而分析对象也是目前为止最为复杂的数据结构：HashMap。在日常开发中 HashMap 的使用率非常高，应该和 ArrayList 不分上下，而且 HashMap 的相关问题是 Java 面试中必然出现的，因此能够从源码层面理解 HashMap 的相关知识点就变得尤为重要。希望接下来的几...

这次番外篇的内容其实挺有意思，领域驱动设计与函数式编程又有什么关系呢？似乎这是八杆子打不着的两样东西，有这样的疑惑很正常，所以不妨继续往下看，听我慢慢的说。

本篇是 TreeMap 和红黑树源码分析的最后一篇了，这次会结合 TreeMap 的源码教大家红黑树删除节点的算法。红黑树的删除算法要比插入更为复杂些，但是也不必担心，本文会用简单明了的解释，并结合 JDK 的源码让你了解红黑树的删除算法。

严格的说事件驱动并不是一种模式，应该是一种架构风格或者编程范式。但是领域驱动设计中事件驱动所涵盖的范围没有那么大，往往只是作为整个系统解决方案的一部分，所以我还是把它归类在模式的范畴内。

上一篇文章中我们介绍了 Map，TreeMap 的接口和内部的数据结构实现：红黑树的概念。今天文章的主要内容是介绍红黑树的核心操作之一，插入操作的代码实现。

许多开发者在项目中希望能够使用 DDD 原因在于能够管理业务的复杂度，避免在业务规则愈发复杂的情况下代码以及架构发生腐化，最终变的难以维护。系统复杂度体现在多个层面，例如繁琐的流程，繁复的校验规则，数据的多样性等，DDD 对于不同层面的复杂度提供了不同的应对模式，今天的文章会聚焦与如何使用 Specification ...

DDD 作为一种系统分析的方法论，最大的问题是如何在项目中实践。而在实践过程中必然会面临许多的问题，「模式」是系统架构领域中一种常见的手段，能够帮助开发人员与架构师在遭遇某种较为棘手，或是陌生的问题时，参考已有的成熟经验与解决方案，从而优雅的解决自己项目中的问题。

上一篇文章中介绍了什么是事件风暴，以及相关的概念。那么这次会通过一个实际的例子带领大家经历一次完整的事件风暴，并且分享自己在使用事件风暴中所遇到的问题。那么就让我们开始吧。

Map 在 Java Collections Framework 中设计相关知识点比较多的数据结构，无论是工作还是面试中都会被频繁的涉及到。通过学习 Map 的源码，我们能够深入理解相当部分的数据结构知识和编码技巧。在接下来的几篇文章中会介绍一些数据结构的知识，希望大家不会觉得无聊，因为这部分的能力才是作为程序员的核心能力。同时这部...

上一篇文章中介绍了 Set 接口和它的两个主要实现，HashSet 和 LinkedHashSet。回忆一下它们的特点，HashSet 特点是无序，而 LinkedHashSet 则是有有序的，它的顺序是按照集合内元素的添加顺序。

前两篇文章介绍了 List 接口的两个实现类，List 数据结构的特定很明显，支持通过序号的随机访问，支持添加重复元素等。而本篇介绍的数据结构 Set 与 List 有较大的差异，Set 不支持添加重复元素，也不支持随机访问某个元素，内部元素的存放也不一定是有序的。下面会介绍 Set 接口的几个实现，帮助大家了解 Set 的具体特...

在我过往的项目经历中，DDD 落地遇到最大的问题会有两个，其一是如何发现系统中的 Aggregate(聚合)，其二是如何划分 Bounded Context(限界上下文)。这两个元素可谓是 DDD 的核心概念，分别对应了单个业务功能模块内核心的领域对象，以及如何划分业务功能的边界。

上一篇 Java Collections Framework 源码分析中我们浏览了 ArrayList 的一些细节，这次分析的是同样实现了 List 接口的 LinkedList。

之前的几篇文章中更多谈及的是有关具体代码层面的设计与实现，这在 DDD 中更多的被成为是「战术设计」，而接下来的几篇文章我会谈及 DDD 中设计的另一部分概念，更加偏向上层的「战略设计」。本篇会介绍「战略设计」的核心概念，Bounded Context，称之为限界上下文(之后简称为 BC)，以及在项目中如何实现。

之前的两篇文章中我们讨论了是领域的对象的核心概念，即什么是 Entity 实体与 Value Object 值对象。以及如何使用 Aggregate 聚合模式来封装 Entity，以保障它数据完整性。而本篇文章会讨论有关领域对象的最后一个部分，如何使用 Factory 工厂与 Repository 仓储模式来管理 Entity 的生命周期。

上一篇中介绍了 DDD 中的核心概念，Entity 实体与 Value Object 值对象的概念，以及如何在项目中实现它们。而本篇文章我会介绍 DDD 中另一个核心概念，Aggregate 聚合。

如果问到 Java 程序员日常用到最多的数据结构是什么？我想不外乎这 3 个： ArrayList，HashMap 和 HashSet。这次我们就来分析其中的 ArrayList 的源码。

上一篇我们介绍了如何在 Clean Architecture 与 DDD 的框架内划分一个项目的层级，而本篇文章中我们会聚焦在整个分层架构的核心部分，领域层中的关键概念: Entity(实体)，Value Object(值对象)。

上图是项目的第一层目录，分为 application，domain，facade，infrastructure 四个部分。接下来分别介绍这四个层的作用。

近几年随着微服务的流行，领域驱动设计(Domain-Driven Design) 重新回到了主流视野中。我自己最早是在大约 2003 ～ 2004 年左右了解到 DDD 的概念，之后一些金融行业的业务系统中尝试运用了 DDD 的理念进行系统设计，期间的确感受到了 DDD 与其他架构设计不同之处，但也遇到了不少问题。之后的几年中，我的工作内容逐渐...

阅读源码是提升编程能力的一项基础技能，但是很多初学者在阅读源码过程中不得其法，往往花费了大量的时间却没有收到预期的效果。或者在阅读过程中无法了解作者的意图，白白错失了学习的机会，因此我希望借助这个系列，通过解读 Java Collections Framework 的源码，给大家归纳 Java Collections Framework 相关知识的同...