领域驱动模型&CQRS学习

1、领域驱动概述

微服务系统的设计自然离不开DDD（Domain-Driven Design，领域驱动设计），它由Eric Evans提出，是一种全新的系统设计和建模方法。DDD事实上是针对面向对象分析和设计的一个扩展和延伸，对技术架构进行了分层规划，同时对每个类进行了策略和类型的划分。领域模型是领域驱动的核心。领域模型通过聚合（Aggregate）组织在一起，聚合间有明显的业务边界，这些边界将领域划分为一个个限界上下文（Bounded Context）。采用DDD的设计思想，业务逻辑不再集中在几个大型的类上，而是由大量相对小的领域对象（类）组成，这些类具备自己的状态和行为，每个类是相对完整的独立体，并与现实领域的业务对象映射。领域模型就是由许多这样的细粒度的类组成的。基于领域驱动的设计，保证了系统的可维护性、可扩展性和可复用性，在处理复杂业务逻辑方面有着先天的优势。

1.1、Spring Cloud与领域驱动

在微服务（MicroServices）架构实践中，大量借用了DDD中的概念和技术，比如一个微服务应该对应DDD中的一个限界上下文（Bounded Context）；在微服务设计中应该首先识别出DDD中的聚合根（Aggregate Root）；还有在微服务之间集成时应该采用DDD中的防腐层（Anti-Corruption Layer, ACL）。我们甚至可以说DDD和微服务有着天生的默契。

注：聚合根的设计尤为重要，如果聚合根设计集中化，会随着后来的业务扩展模型越来越庞大，会导致一系列的内存、性能等问题，而且几乎不可能解决，除非重构聚合根设计。

1.2、为什么需要领域建模

领域模型有助于团队创建一个业务部门与IT部门都能理解的通用模型，并用该模型来沟通业务需求、数据实体、过程模型。模型是模块化、可扩展、易于维护的，同时设计还反映了业务模型，提高了业务领域对象的可重用性和可测性。反过来，如果IT团队在开发大中型企业软件应用时不遵循领域模型方法，不投放资源去建立和开发领域模型，会导致应用架构出现“肥服务层”和“贫血的领域模型”，在这样的架构中，会积聚越来越多的业务逻辑。我们希望领域对象能够准确地表达出业务意图，但是多数时候，我们看到的却是充满getter和setter的领域对象。此时的领域对象已经不是领域对象了，它们只是个数据载体，也就是Martin Fowler所说的贫血对象。这种做法会导致领域特定业务逻辑分散在一堆service层中，软件架构随业务开发常年累积野蛮生长，从而腐败，无法维护。

领域驱动设计告诉我们，在通过软件实现一个业务系统时，建立一个领域模型是非常重要和必要的，因为领域模型具有以下特点：
❑ 领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反映了我们在领域内所关注的部分。
❑ 领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物、书本、应聘记录、地址等；还能反映领域中的一些过程概念，如资金转账等。
❑ 领域模型确保了我们的软件业务逻辑都在一个模型中，这样对提高软件的可维护性，业务可理解性以及可重用性都有帮助。
❑ 领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造。
❑ 领域模型贯穿软件分析、设计及开发的整个过程；领域专家、设计人员、开发人员通过领域模型进行交流，彼此共享知识与信息；因为大家面向的都是同一个模型，所以可以防止需求走样，可以让软件设计开发人员做出来的软件真正满足需求。
❑ 要建立正确的领域模型并不简单，需要领域专家、设计人员、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细