大白话翻译领域驱动设计的部分概念

DDD

  大多数人刚开始看这个东西时就跟听那些不说人话的互联网八股文是一模一样。就像某人介绍自己是互联网设备终端安全防护工程师，实际上是给手机贴膜。DDD吹得神乎其神但这个东西就是一层窗户纸，目前而言这个思想很难落地实现，即便是BAT大厂也只是尝试着将非常小的项目用这个来实现一下，本文将对比着MVC传统架构讲一下个人见解(可能也有理解有偏差的地方)。

白话文解释

  DDD全称 Domain-Driven Design，意思是领取驱动设计，是一种开发和设计的思想。是最近几年SOA架构下比较火热的一种思想。DDD分为两部分，一部分是战略设计，另一部分是战术设计。战略设计提出了域、子域、限界上下文等概念，主要用于指导我们如何拆分一个复杂的系统，比如系统刚建成时订单、搜索、用户等都是集成在一个工程里的，后期拆分成了订单系统、推荐系统、用户系统、物流系统等等，每个系统都是一个领域。战术设计提出了实体、值对象、聚合、工厂、仓储。领域事件等概念，主要用于指导我们对于拆分出来的单个域如何进行落地，以及落地过程中需要遵循的原则。这个有些像MVC，指导我们在实际写程序时怎么去拆分对应的包，在哪些包中定义对应的类等等。
  领域个人理解就是领域模型，上面提到把一个大的系统划分成若干个子系统，这些子系统就叫做一个个小的领域，而这一个个的小的系统就是一个个的领域模型，比如订单系统就是订单领域。
  设计个人理解就是写代码，就是真正去干活。所以领域驱动设计说白了就是怎么去划分领域，从而建立领取模型，按照这个领域模型的去写代码，能够使代码更好地表达设计含义，并且使模型与实际的系统相契合。划分领域后什么代码该写在什么领域里是严格按照领域模型来的，比如退货退款的代码不能写在推荐商品的领域里，而退款页面想推荐其他商品就要去调用推荐领域的接口，而不能自己写一套推荐的代码。这跟SOA的思想好像差不多。

战略设计

  战略设计属于宏观层面的内容，上面也提到过，就是把一个大的系统分成若干个子系统，怎么划分这就是所谓的战略设计。经过战略设计后，一个大的领域划分为了若干个子领域。比如购物系统划分出的其中一个子领域是订单领域，那订单领域从整体层面来看是整个购物系统子领域。划分领域的同时又定义了界限上下文，界限上下文划分了这个界限内的领域与其他界限内的领域之间的关系。就像下面这张图，登录和订单都用到手机号，但是登录里面的手机号是作为用户名来使用，而订单里的手机号是作为订单号的组成部分来使用，虽然是同一个手机号但是受制于这个边界的划分，所以用处不同，一般一个界限上下文里可能包含了多个领域，一个领域也有可能处于多个界限上下文中。