业务|如何从0到1实践DDD 使命|价值观|诚信采销|买道议

编辑导语：DDD（Domain-driven design，领域驱动设计）是一种架构设计方法论，通过边界划分，将复杂业务领域简单化，帮助我们设计出清晰的领域和应用边界，保证业务模型与代码模型的一致性。本文作者结合实际经验，介绍了如何从0到1实践DDD，一起来看看吧。

文章插图
随着业务的不断发展，我们发现自己的系统开始变得有点臃肿，为了减少复杂性，我们尝试借助DDD来改善我们的系统。本文记录了自己对DDD的理解和实践过程，欢迎大家一起探讨。见识所限，难免有理解不到位，希望路过的大佬不吝赐教。
一、为什么需要DDD

当朋友和你聊工作时，你能否一语中的，说清你在开发中的业务内容及其价值？
当产品和你聊需求时，你是否遇到过反复沟通之后才发现讲的不是同个东西的情况？
当你在做需求评估时，你是否经常发现一个小的需求改动，总是牵一发动全身？
当你在快乐写代码时，你是否经常觉得有些类可有可无，有些接口望文不知义？

如果你有以上的一些疑问，那你可以试试领域驱动设计：
DDD（Domain-driven design，领域驱动设计）是一种架构设计方法论，通过边界划分，将复杂业务领域简单化，帮助我们设计出清晰的领域和应用边界，保证业务模型与代码模型的一致性。
在细看这个定义之前，我们可以思考一下，为什么我们的业务系统会慢慢变得复杂？
常见的情况是，业务在发展过程中为了探寻发力点，需要不断地试错迭代，调整方向，而系统在设计之初，难以预期到后面的瞬息万变，为了应付业务，修修改改，久之，系统也变得复杂起来。
可以怎么办呢？及时重构呗——不改变软件系统外部行为的前提下，改善它的内部结构。
然而重构是从技术层面上抽炼出来的模型，往往不具有实际的业务含义，其他同学可能难以自然地将业务问题映射到对应的设计模型。另外，如果不能如实映射业务模型，随着业务方向调整，代码可能又开始腐败……有点像芝诺悖论中，阿基里斯永远追不上小乌龟。

文章插图
那DDD怎么搞？
DDD是这么想的：”将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构”。可能大家平时有这样的想法，但是比较模糊，未形成体系，而DDD就提供了一套完整的方法论。从业务角度去审视我们的系统，从而实现高内聚低耦合的代码。
整体而言，领域驱动设计包括战略建模和战术建模: 战略设计侧重于高层次、宏观上去划分和集成限界上下文，而战术设计则关注更具体使用建模工具来细化上下文。
二、如何实现DDD之战略建模1. 基本概念1）领域、子域
在讨论问题之前，我们需要先定义好问题。
领域即问题域，通常是根据一个组织所处的行业进行识别，它基于业务的愿景，定义了系统要解决的现实问题的目标和范围。领域越大，业务的范围也越大，大的领域可以拆分成小的问题域，称之为子域。根据子域重要性和功能属性划，可以将其分为三类。
核心域、支撑域和通用域：

核心域：决定产品核心竞争力的子域
支撑域：实现核心域目标所需的，但重要程度不如核心域的子域，一般具备强烈的个性化需求
通用域：具有通用功能，可被多个子域使用的的是通用域。该子域所解决的问题一般是业界常见问题，有成熟的解决方案，可直接购买或简单修改来使用
- 上一页
- 1
- 2
- 3
- 4
- 5
- 下一页