1 前语

本文与咱们一同学习并介绍范畴驱动规划(Domain Drive Design) 简称DDD，以及为什么咱们需求范畴驱动规划，它有哪些优缺点，尽量用一些浅显易懂文字来描绘解说范畴驱动规划，本篇并不会从深层大论说解说落地完结，这些咱们能够在了解入门后再去深层次学习讨论或在后续进阶和高档篇了解，希望经过本文介绍，能够让咱们快速了解DDD并有一个根底的认知，DDD自身便是理论的调集，很难在不堆集理论状况下来有用的施行DDD，仅仅看一些代码事例后就开搞,终究出来东西也是东施效颦，莫要好大喜功。 最终希望咱们在工作中能多考虑，如你所担任项目假如用DDD怎么规划、以及会面对哪些应战。

学习了解DDD之前，希望咱们可在温顾下以往咱们所了解把握一些常识，尽力让自己所学所把握的内容沉积下来，引荐阅览系列。

• Head First 规划形式:根底面向目标概念和重要的规划形式；
• UML面向目标建模根底:从需求到剖析，从剖析到规划，从规划到编码，UML都有用武之地
• 完结范畴驱动规划：很厚，愈加务实，引荐阅览
• 范畴驱动规划：张逸-DDD开山之作，挺玄幻的，多读几遍收获颇丰；

2 界说与概念

范畴驱动规划(DDD)提出是从系统的剖析到软件建模的一套办法论。将事务概念和事务规矩转换成软件系统中的概念和规矩，然后下降或躲藏事务杂乱性，使系统具有更好的扩展性，以应对杂乱多变的实践事务问题。总结它是一套完好而系统的规划办法、是一种规划思维、一种办法论，并不是"系统架构"，一种架构规划准则、思维。

2.1、为什么要运用"范畴驱动规划",或许说其用处,运用场景式什么?

1. 长于处理高杂乱事务的产品研制、可协助咱们提炼安稳的产品内核(范畴模型中称为中心域);

2. 经过建模可进步建模高内聚、下降模型间的耦合度，进步系统的可扩展性与安稳性;

3. 着重团队与范畴专家的协作交流，有助于树立一个交流杰出的团队安排；

4. 共同规划思维与规划规范，有助于进步团队成员的架构规划能力和面向目标规划能力;

5. 现有的微服务建构都是遵从范畴驱动规划的架构准则;

6. 假如你担任的软件系统并不杂乱，那么，你的确不需求学习范畴驱动规划!

2.2、范畴驱动规划跟时下盛行的架构思维最大的差异是什么？

范畴驱动规划的思维是：目标+行为+服务，全部的规划围环绕着目标、行为、服务打开；

时下盛行架构规划思维是：根据MVC分层架构进行纵向扩展，分事务模块进行产品横向扩展;

2.2.1. 传统的计划

三层运用架构：数据-运用(事务逻辑层)-展示，一般是以数据位为起点进行数据库剖析规划。

1. 服务层过重，数据模型失血，没东西；

2. 面条式编程或许面向数据库编程，服务层环绕数据库作业完结事务逻辑，常常一条线撸究竟；

3. 代码一整块一整块的过重，很难扩展复用；

4. 数据库模型仅仅数据库映射，没有相关的行为支撑，行为都被上一层Service给完结等了，因此是失血 的范畴模型；

2.2.2. 范畴驱动计划

架构四层在DDD分层结构中将三层中事务逻辑拆解为运用层和范畴层，中心事务逻辑表现下沉到范畴层去完结，以事务范畴模型为中心建模(面向目标建模)，更能表现对实践国际的笼统，其长处如下

1. 轻服务层+充血的范畴模型；
2. 范畴模型封装和完结各自应有的行为，能够认为是一个高内聚、低耦合的组件；
3. 因为模型集数据与行为于一身，是一种自解说的目标，代码复用性高，事务逻辑明晰明确;

• 用户界面层：首要职责是经过用户界面向用户显现数据信息，一起解说用户的指令，并把用户的恳求发送到运用层。
• 运用层：经过调用根底设置和范畴层完结数据资源操作及事务流程编列，相当于BS层；
• 范畴层：将事务逻辑高度内聚到范畴层，所以范畴层是整个系统的中心，它只与实践事务相关，不关心任何技能细节，尽可能做到与耐久化无关；
• 根底设施层：包括了任何类型的结构、数据库拜访代码或许公共的办法等，纯技能的一层；

2.3、怎么学习范畴驱动规划

没有谁能够做到范畴驱动规划的一蹴即至，所谓"理论联系实践"，在刚开始触摸或学习规划范畴驱动时，总会有一种诉求希望能给出公式般的规划准则或规范，好像软件规划就像拼积木一般，只需遵从图示给出的拼搭进程，不经考虑就能拼出等待的模型，这好像不切实践的梦想，要把握范畴驱动规划，首先要了解把握一些概念以常识理论，在此根底之上考虑这些概念背面包括的原理，规划准则，考虑限界上下文(Bounded Context)鸿沟的区分，实践仍是环绕"高内聚、低耦合"准则的表现，仅仅咱们考虑什么内容才是高内聚，怎么笼统才干做到低耦合，在分层架构中，各层之间该怎么协作？呈现了依托怎么解耦，依然需求从重用与改变的视点去考虑规划决议计划。

3 范畴驱动规划

范畴驱动规划着重以"范畴"为中心驱动力，经过模型驱动规划来确保范畴模型与程序规划的共同,范畴模型不应该包括任何技能完结要素，模型中的目标实在的表达了范畴概念，却不受技能完结的束缚，范畴模型自身和技能无关，范畴驱动从规划上区分为战略规划和战术规划。

• 一个范畴是由一个或多个模型组成；
• 从界说上讲模型是范畴的笼统；
• 从了解大将模型能够认为是一个高内聚、低耦合的组件、模块，也能够称为一个子范畴;
• 模型重在建模进程，建模进程会笼统出一系列范畴目标和范畴服务；
• 在DDD中，界说一系列的规范"范畴元素"用于范畴建模；如战术规划元模型

3.1. 战略规划

着重事务战略上的要点，怎么按重要性分配工作，以及怎么进行最佳，遵从量大准则：

1. 有必要辅导规划决议计划，以便削减各个部分之间的相互依托，在运用规划目的更为明晰的一起而又不失掉要害的互操作性和系统性；

2. 有必要把模型的要点放在捕获系统概念中心，也便是系统的"前景"上。

3.1.1 子域区分

整个事务范畴的一部分，重视与微观事务，经过对大范畴进行划小在事务间区分出概念上分界线，便于在系统谋划阶段决议计划怎么分配资源(人、钱)。

1. 中心子域：范畴中最有价值和最中心的部分，产品胜败的要害，中心竞争力,在DDD开发中，首要重视核 心域，给予最高优先级;
2. 支撑子域：项目中对中心子域起着支撑效果的相关功用，专心于事务的某个不和;
3. 通用子域：与项目目的无关的内聚子范畴，处理一些通用问题，任何专有的事务都不应该放在通用子域;

3.1.2. 战略建模

重视点在于系统物理区分，根据你对范畴的切割成果及公司或部分的安排结构决议计划怎么区分子系统，比方分出几个，系统间怎么交互，该层面往往暂不会触及够多技能细节。

1. 限界上下文(Bounded Context):浅显讲指系统中模块，微服务架构中的子服务、单体中"包(Java)"或称号空间(C#)，对系统的一个物理区分，约束了范畴模型的鸿沟，在更深层次介绍深挖，这东西得分红两个词：限界、上下文，能够了解成系统规划之初，你需求画一个圈设置一个规划，确保范畴模型约束在这个圈内不行串场，这个‘圈’即为限界上下文。
2. 通用言语:用于共同范畴专家、产品、研制、测验咱们在运用的言语，防止呈现需求了解不共同，规划与需求不共同，交流不顺利等问题，简略来说咱们在一同聊某个东西的时分都能理解互相所造成的的是什么，场景不同，同一个词就会有着不同意义。
3. 上下文映射图：用图的方法，表达出限界上下文之间相关,后续会独自在具体介绍上下文映射图，如 协作联系、防腐层、大泥球等；

3.2. 战术规划

依托于范畴模型和通用预言，经过技能形式将范畴模型和通用预言中的概念映射到代码完结中。跟着模型的进化，代码完结也会进行重构，以更好的表现模型概念。

• 首要包括：

1. 代表范畴中的概念，如实体、值目标、范畴服务、模块等；

2. 用于办理目标的生命周期。如聚合、工厂、库房等;

3. 用于集成或盯梢，如范畴工作等;

3.3. 名词解说

1. 范畴/子域：什么范畴？从广义大将，范畴便是一个安排所做的工作以及所包括的全部，范畴可大可小有边界，不是无限大，如电商范畴，买卖范畴，购物范畴等，比方咱们常听客户说“咱们有这样几块事务”一般来说这儿所谓"几块儿"便是指子域 。

2. 实体(entity)：这个词被咱们广泛运用，乃至过火运用，实体是一个重要的概念，一个典型实体应具有3个要素(身份标识、特点、范畴行为)，有必要有仅有的身份标识，没有身份标识的范畴目标就不是实体。如：User目标便是一个实体。

3. 特点：实体的特点用来阐明主体的静态特征，并持有数据与状况。

@Data
public class Product{
    private String sku;
    private String name;
    private Price price;
}

1. 范畴行为：实体具有范畴行为，能够更好地阐明其作为主体的动态特征。一个不具有动态特征的目标不属于范畴行为。

@Data
public class Product{
    private String sku;
    private String name;
    private Price price;

    //改变状况的范畴行为
    public void changePriceTo(Price newPrice){
        //规划产品新加个
        .......
        
    }
}

1. 值目标(value object)：比较笼统，一般作为实体的特点，区分值目标与实体的差异在于，值目标是不行变的，而且没有仅有标识，仅由其特点的值界说，参加则对它的判别是根据值仍是根据身份标识，前者是值目标，后者是实体；

举个小比如：订单项和订单的联系：多对一，一个订单里有多条订单项，一个订单项，只会呈现在一个订单里，组合联系，部分不能脱离主体独自存在

public class Order {
    int id;
    User user;
}

public class OrderItem {
    private int id;
    private Product product;
    private int num;
    private Order order;
}

6)  聚合根：聚合中需求指定一个实体作为聚合根来作为整个聚合的对外触电，也便是说外部只能经过聚合根完结对内部目标的拜访，这样的约束能够对内部目标完结最大化的维护。

4 价值是什么

简直全部项目的开展都有这样一个规则：初期需求简略，中后期事务激增系统杂乱度晋级，导致开始的规划理念需求雷厉风行的变革，所以，系统越杂乱、代码规划越大，DDD 的优势就越显着。

• 协作交流：着重团队与范畴专家的协作交流，有助于树立一个交流杰出的团队安排；
• 共同思维：共同规划思维与规划规范，有助于进步团队成员的架构规划能力和面向目标规划能力；
• 系统灵敏：经过建模可进步模型的高内聚，下降模型建的耦合度，进步系统的可扩展性与安稳性；
• 产品内核：长于处理高杂乱度事务产品研制，可协助咱们提炼安稳的产品内核；
• 事务沉积：范畴模型是系统的中心，是范畴内事务的直接沉积，具有非常大的事务价值。

5 根底篇结束语

微服务区分的一个重要理论根底便是范畴驱动规划，但因为DDD门槛高、概念多，系统巨大又笼统，再加上实践经验和事例短少，许多开发人员对DDD存在不少疑问，或只停留在平常依托检索或身边搭档谈及耳闻了解DDD，经过本篇开始认识了范畴驱动规划、前期咱们先暂短介绍这儿，后续会将从代码层面下手共享DDD完结落地。

作者：京东物流 边雷

来历：京东云开发者社区 自猿其说Tech 转载请注明来历