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,简单介绍一下,后边继续……

猜你喜欢

转载自blog.csdn.net/liujiahan629629/article/details/105303263