提取码：45on
领域驱动设计(DDD)，因非常适合与微服务进行配合而闻名，因《领域驱动设计》那本书的难懂而让人望而却步。
其实《领域驱动设计》这本书讲的是：以领域为核心，在代码中体现领域的思想，开发人员和领域专家要紧密沟通。这也侧面给出了公司划分组织结构的建议。
开始之前，我要声明一点：领域驱动设计不是万能药，它适合于实时系统，而对于分析汇总的场景，则不必使用领域驱动设计。
技术是在进步的，现在大家对领域驱动设计抽象的越来越好。今天就来总结一下领域驱动设计简单易用的技巧。首先声明一下：提到的技巧不一定是领域驱动设计提出来的，但是这些技巧可以帮助我们更好的进行领域驱动设计。
限界上下文
画架构图尽量简单易懂。但是项目本身很复杂怎么办呢？那就要按问题域划分子域。每一个子领域架构是很简单的，想看到全貌可以将它们之间的关联形成上下文地图。这就是限界上下文的作用。 这类设计原则的应用非常广泛，我现在所在的Java Web项目就是使用这样的设计原则进行架构设计的，基本都是常见的三层或多层架构，他们大概是什么样的呢？
Web层（俗称展现层吧，Presentation Layer)：接收用户输入，将数据传至服务层；
服务层(Service Layer，可以叫Business Logic Layer)：事务边界，处理业务逻辑、权限管理与授权，并与存储层通信；
存储层（Data access layer）：与数据库进行通信，对数据进行持久化。
但是发现什么没有？问题出在了服务层，他承受了太多的职责，像事务管理、业务逻辑、权限检查等等，这违反了单一职责原则和关注分离原则，并且产生了大量的依赖和循环依赖。当业务复杂度上升时，服务层所包含的代码将会非常庞大和复杂，直接导致了测试成本的上升。
我这里正好有个例子，在现在的项目中，负责处理保险业务单的核心类中，包含了4000多行代码，它与数据库中某一关键表相关联，引用（注入）了十几个DAO。在数十个各类方法中，可以处理保单、再保、理赔等等各种不同的业务，同时它还深度依赖于hibernate，不但使用了ORM方法处理数据，甚至还直接用了HQL来获取数据。因为有众多其他服务类与他进行循环引用，项目后期这个庞然大物已经没有人敢轻易改动了，因为谁也不知道他到底都能做什么，重构更是不可能的事。
