认识达内从这里开始

我们在前几期的文章中给大家简单介绍了领域驱动设计的概念与应用等技术知识点，今天合肥达内培训就再来说说，领域驱动设计都有哪些战略和战术方法。

领域驱动设计强调以"领域"为核心驱动力，通过模型驱动设计来保障领域模型与程序设计的一致,领域模型不应该包含任何技术实现因素，模型中的对象真实的表达了领域概念，却不受技术实现的约束，领域模型本身和技术无关，领域驱动从设计上划分为战略设计和战术设计。

一个领域是由一个或多个模型组成;

从定义上讲模型是领域的抽象;

从理解上将模型可以认为是一个高内聚、低耦合的组件、模块，也可以称为一个子领域;

模型重在建模过程，建模过程会抽象出一系列领域对象和领域服务;

在DDD中，定义一系列的标准"领域元素"用于领域建模;如战术设计元模型

战略设计

强调业务战略上的重点，如何按重要性分配工作，以及如何进行佳，遵循量大原则：

必须指导设计决策，以便减少各个部分之间的相互依赖，在使用设计意图更为清晰的同时而又不失去关键的互操作性和系统性;

必须把模型的重点放在捕获系统概念核心，也就是系统的"远景"上。

子域划分

整个业务领域的一部分，关注与宏观业务，通过对大领域进行划小在业务间划分出概念上分界线，便于在系统筹划阶段决策如何分配资源(人、钱)。

核心子域：领域中有价值和核心的部分，产品成败的关键，核心竞争力,在DDD开发中，主要关注核心域，给予高优先级;

支撑子域：项目中对核心子域起着支撑作用的相关功能，专注于业务的某个反面;

通用子域：与项目意图无关的内聚子领域，解决一些通用问题，任何专有的业务都不应该放在通用子域;

战略建模

关注点在于系统物理划分，根据你对领域的分割结果及公司或部门的组织结构决策如何划分子系统，比如分出几个，系统间如何交互，该层面往往暂不会涉及够多技术细节。

限界上下文(BoundedContext):通俗讲指系统中模块，微服务架构中的子服务、单体中"包(Java)"或名称空间(C#)，对系统的一个物理划分，限定了领域模型的边界，在更深层次介绍深挖，这东西得分成两个词：限界、上下文，可以理解成系统设计之初，你需要画一个圈设置一个范围，保证领域模型限制在这个圈内不可串场，这个‘圈’即为限界上下文。

通用语言:用于统一领域、产品、研发、测试大家在使用的语言，避免出现需求理解不一致，设计与需求不一致，沟通不顺畅等问题，简单来说大家在一起聊某个东西的时候都能明白彼此所致的是什么，场景不同，同一个词就会有着不同含义。

上下文映射图：用图的方式，表达出限界上下文之间关联,后续会单独在详细介绍上下文映射图，如合作关系、防腐层、大泥球等;

战术设计

依赖于领域模型和通用预言，通过技术模式将领域模型和通用预言中的概念映射到代码实现中。随着模型的进化，代码实现也会进行重构，以更好的体现模型概念。

主要包括：

代表领域中的概念，如实体、值对象、领域服务、模块等;

用于管理对象的生命周期。如聚合、工厂、仓库等;

用于集成或跟踪，如领域事件等;

名词解释

领域/子域：什么领域?从广义上将，领域即是一个组织所做的事情以及所包含的一切，领域可大可小有界限，不是无限大，如电商领域，交易领域，购物领域等，比如我们常听客户说“我们有这样几块业务”一般来说这里所谓"几块儿"就是指子域。

实体(entity)：这个词被我们广泛使用，甚至过分使用，实体是一个重要的概念，一个实体应具备3个要素(身份标识、属性、领域行为)，必须有的身份标识，没有身份标识的领域对象就不是实体。如：User对象就是一个实体。

属性：实体的属性用来说明主体的静态特征，并持有数据与状态。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。