领域模型为核心的架构设计 初篇

写在前面

参加了一个培训，主题就是以领域模型为核心的架构设计。很受启发，想着把思考，分享出来，大家可以在设计之路上，有所参考。

本篇文章，大致上从以下几个方面展开：

• 目前项目进展过程中的痛点

• 领域模型的概念

• 模型的必要性

• 领域模型的优势

项目痛点

从一些故事说起吧。

A

话说，在一个科技公司，开发人员大量辞职，均不同程度的产生焦虑、恐惧的情绪。公司高层都蒙了，开始调查原因。最终发现，公司里制度比较严格，对于上线的 bug，会扣绩效、罚款。所有开发人员、测试人员，每个周的多次发版，都是战战兢兢。永远都是未知的问题占据了上风。很多时候，有可能不是新需求带来的问题，反而是老的业务需求，发生的问题。不管测试人员多努力，很多时候，就是会发生未知的问题。代码审核、管控，此时也都失效。久而久之，恐惧占据了心扉。

B

有一家中小微互联网企业，本来的架构比较传统，因为业务量没有那么大，采用了传统的单体结构。随着业务的开展、公司的发展，也是因为新来了一个技术总监，新人新气象，准备大刀破斧的实施技术改革，准备切换到微服务架构。对系统做新的重构，本来应该好好梳理出相关的业务场景、业务逻辑，但是可能时间紧迫，比较急于求成，导致服务拆分，乱七八糟，业务实现问题很多，系统产生了各种问题，严重影响了线上的业务。最终迫不得已，重新切换回了原架构。

上边两个故事，正是很好的描述了，项目开展进程中的一些痛点。

1. 开发测试和代码审核管控无效，带来更多的未知问题

2. 项目重构，造成更复杂问题，难以保证合理重构

总结看来，就是技术债务，严重影响了组织生产力。

项目开展过程中，基础没有做好，就会遗留一堆的技术问题，久而久之，就产生了技术债务。包括遗留 bug、不规范设计、不合理业务流等等各个方面。技术债务的出现，严重影响了组织生产力。一代老人去，一代新人来。积攒的问题，最后爆发，会带来意想不到的巨大损失。

领域模型的概念

领域模型，用来描述现实世界的实体以及实体之间的关系。

领域模型，是对问题空间的理解。

举个例子说明，现在有个业务场景。说一个线上项目，场景为，用户需要拼车，然后线上下单，描述路程与出行时间，寻找车辆与同行的人，然后选择支付缴费方式。那么，我们用领域模型来描述，如下图所示：

领域模型的必要性

建立领域模型的必要性，大致上存在以下几点内容：

1. 目前开发效率提升和业务发展要求存在冲突，没有很好的手段，来提升生产力，解决技术债务带来的影响。

2. 不良的业务分析、架构设计基础之上，推动技术变革、发展，推动实施微服务、中台化，往往促使，矛盾更加凸显

3. 未来技术发展，是云原生的未来。那么需求分析、架构设计、实现能力，都将回归基本能力。

需要有一种手段，来贯穿软件开发的整个生命周期。建立一门统一语言，来解决目前技术债务的痛点。

领域模型的出现，通过：

• 业务引领的领域建模

• 领域驱动的微服务架构

• 契约导向的软件实现

完成，更好的高效的技术实践。经过实践来看，采用领域模型，至少提高 10 倍的生产力。

领域模型的优势

构建领域为核心的高效技术实践，需要领域模型的引领全局。

在软件开发中，认知是软件开发中的核心任务。

多少个软件开发中，因为产品经理和开发人员因为概念理解等问题闹得不可开交。对一件事情的认知，尤其重要。当然不仅仅体现在软件开发中。

举个例子讲，谈恋爱还得讲究三观一致，要不然，最终结局也估计不是理想的。

那么，对领域的认知，是一家企业的根本能力和竞争力。只有掌握好，自己公司领域的认知。达到全员一致化，那才能顺畅的开展一切的业务。

缺乏领域模型的信号：

1）组织没有概念共识

2）沟通误解不必要的需求

该信号，正是凸显了认知的存在性和必要性。

一个高质量的领域模型有以下特点：

• 建立共识

• 产生洞察

• 持续演进

领域模型，它不是分析阶段的产物，是贯穿整个软件开发的过程。

分析阶段，领域模型，构建共识

开发阶段，领域模型，引领开发

测试阶段，领域模型，可以自动化测试

总结

构建以领域模型为核心的高效架构实践，是指导我们软件开发的必然实践。

​