DDD领域驱动（一）——之引入

         随着近几年的微服务的兴起，随着15年阿里中台的提出，其火热程度大家都可以看到。无论公司大小大家都在做中台，都在搭建微服务。但是怎么能够做一个好的中台，怎么能够拆分一个大小合理的微服务呢？

---

         好，我们先看一下面向对象的基础（具体含义这里不展开）：

         三大基本特征：封装、继承、多态；

         六大原则：单一职责原则（SingleResponsibility Principle，简称SRP）、开放—封闭原则（OCP，OpenClosed Principle）、依赖倒转原则（DIP,DependenceInversion Principle）、里氏代换原则（LiskovSubstitution Principle， LSP）、迪米特法则（LawofDemeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP）、合成聚合复用原则（CompositionAggregationReuse Principle ,CARP）。

---

       思考一下我们的目标是什么？答案：设计编写出【高内聚、低耦合】的程序，达到【可扩展、可复用、灵活性强】的目标，从而能够更高效的应对业务需求的变化。（更多的从编写程序的角度进行思考的）

         中台，当今互联网时代，用户是商业战场的中心，快速响应用户的需求，快速进行产品的创新、迭代、重组等，“快”字成了当今互联网的关键字，而中台，就是抽象、沉淀企业的一些通用、核心服务能力，达到能够快速支撑前台，快速响应用户需求的能力。（更多站在企业的角度进行思考）

         类比一下，中台中的一个服务能力（被多个业务线复用），和程序中的一个类（被多个功能方法复用）。其实细细思考有很多相通、相似的地方。（再思考类比一下我们的现实生活：胳膊、人、单位、地区、国家……，都是高内聚，聚合起来干大事）但是编写程序，有一套原则，一套方式方法论。而如果变成企业级的，从大的角度来思考做事的话，就需要另一套方式方法论。但是记住一点：目标本质还是一样。善于抽象挖掘事务的核心本质，很多东西非常容易理解的。

         好，如何在企业中搭建开发一套中台式的系统呢？面对复杂庞大的业务，如何化繁为简，化大为小，让同事更加的容易的参与进行做贡献呢？答案：微服务。微服务的本质就是将原来一个复杂的大系统，大业务，通过合理的划分，形成高内聚的一个个小系统。从而更加容易的沉淀企业业务中的各种能力。所以微服务是实现中台的一种方案。好，如何进行微服务的设计呢？如何进行微服务的划分呢？如何进行服务的实现呢？DDD（领域驱动设计）来了，就是指导我们进行微服务落地的思想。终于引入了DDD，这里我说一下我对三者的理解吧：中台企业级业务能力复用的一种形式，而微服务是落地中台的一种比较合理的技术方案，而DDD则是指导我们如何落地微服务的一种指导思想。

---

         再说DDD以前，大家可以看一下软件工程的一些知识《系统开发与软件工程》。其实我们的软件工程中的几个生命周期：需求分析、架构设计、详细设计编码实现、软件测试、上线后升级维护。而项目管理贯穿各个节点。而DDD也离不开这些东西，看下我从大的方面概况了解一下DDD。

        DDD（Domain-Driven Design）领域驱动设计，领域，百科解释指一种特定的范围或区域。微服务的划分其实就是划分区域，而DDD正是在领域的角度，驱动进行软件设计。这篇，我们先从总体看一下DDD的轮廓，看下边这张图：

        上图右边是DDD领域驱动设计过程，涉及的点，通过领域、需求、业务的角度进行设计，拆分，自顶向下，逐层分解。而左边，是DDD领域驱动设计过程，离不开的三大管理：需求、项目、团队。

 

          好，这篇引入DDD，简单介绍一下，后边继续……