领域驱动设计(DDD:Domain-Driven Design)
领域驱动设计(DDD:Domain-Driven Design)
Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD，Evans DDD是一套综合软件系统分析和设计的面向对象建模方法，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。
回顾历史： 服务器后端发展的三个阶段
UI+DataBase
最原始的两层架构，这种面向数据库的架构完全没有灵活性！
UI+Service+DataBase
多层SOA架构, 这种服务+表模型的架构易使服务变得囊肿，难于维护拓展，伸缩性能差。
SOA通过服务这个中间概念，可以实现业务和技术之间的无缝转换，如今SOA已经和REST DDD以及云计算等新技术方法结合。其内部主要概念有SCA ESB JBI等等，涉及工作流 规则引擎 消息总线等多个技术细节方面。
SOA的不足
服务的抽象主要是从重用角度抽象的，如有很多客户都要下订单，那么我们就抽象一个订单服务提供给这些客户；然后又有很多客户要签合同，那么我们就抽象一个合同服务于这些客户；这些服务都是从对外接口的角度粗粒度设计，或者只是纯粹从业务流程来考虑的，并没有从业务内部领域逻辑角度考虑，有人说，这两者不是一样吗？有时一样，有时不一样。比如某个单位无论给订单客户还是合同客户，都有一个统一的最低底线价格，按照面向服务的设计，这个底线价格会各自写到订单服务和合同服务中。
有人说，那订单服务与合同服务共同重用一个实体名叫价格策略。这种重用其实引发了依赖，紧耦合，破坏了松耦合。
这两个服务都依赖PricePlocy，就算PricePlocy是个接口，如果接口发生变化，这两个服务的代码就发生变化。
那么有人说，将PricePlocy独立出来成为一个PricePlocyService，三个服务通过ESB消息总线交互。那这样服务的粒度就太细了，如果再发生PricePlocy2，难道你再搞个PricePlocy2Service吗
DDD+SOA
事件驱动的CQRS读写分离架构，应付复杂业务逻辑，以聚合模型替代数据表模型，以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。
DDD革命性在于：领域模型准确反映了业务语言，而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法。
DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。
DDD落地实现离不开in-memory缓存、 CQRS、 DCI、 EDA或Event Source几大大相关领域。
SOA到DDD迁移
将业务逻辑从服务层迁移到域模型类有下面三个优势：
- 我们的代码将以逻辑方式切割，服务层只要关注应用逻辑，而我们的领域模型关注业务逻辑。
- 业务逻辑只存在一个地方，容易发现修改。
- 服务层的源代码是清洁的，不包含任何复制粘贴代码。
