程序员到架构师，架构模型不能脱离实际代码

---

前言

想象一下，现在的软件开发越来越被当成工厂的流水线，经验丰富的架构师仿佛是那些精心设计模具的老师傅，而技能水平较低的工人则负责在流水线上把原材料倒进模具里，期待着成品出现。但是，现实远非如此简单。

这种思维模式，就好比是让米其林大厨只负责菜单设计，而让实习生去实际烹饪，结果往往是菜肴难以入口，顾客抱怨连连。因为软件开发的本质，就像是烹饪一道精致的法式大餐，每一步都充满了创意与精细的调整，每一环节都需要那份匠心独运。

尽管开发团队中每位成员都扮演着各自的关键角色，但如果我们把软件开发中的分析、建模、设计和编程工作看作是孤立无关的环节，就像是把烹制美食的过程拆分成买食材、洗菜、切菜和炒菜四个完全不相干的任务，最终得到的可能只是一顿杂乱无章的快餐，而非那令人垂涎三尺的佳肴。

因此，过度分离这些环节，不仅会破坏模型驱动设计（MODEL-DRIVEN DESIGN）的和谐，也会让我们的项目像是一艘没有舵手的船，失去了前进的方向，最终搁浅在困境的沙滩上。

---

一、现实场景中的架构师

在我任职的一家企业中，架构师与开发人员分属不同部门，各司其职。架构师们认为自身的主要任务在于架构设计与模型构建，对于编写业务代码、钻研业务细节则视为无谓的消耗，于是他们的日常便是沉浸在设计架构与模型构建中，随后召集开发人员举行一场讲解会，便视为任务基本完成。然而，随着项目进入迭代阶段，许多前期精心规划的模型并未发挥预期作用，甚至与原始设计背道而驰。

为找出症结所在，我们拉着开发人员一同讨论，归纳出两大主要原因：

首要问题在于模型的意图在传递过程中出现了断层。一个模型的实效性往往取决于那些藏匿于细微之处的设计意图，它们并不总是能在UML图表或常规讨论中清晰显现。若架构师能放下“设计师”的身段，实实在在地与开发人员并肩协作，亲手写下一些业务代码，或提供面对面的技术支持，或许能帮助开发人员更好地领悟模型中的抽象理念，进而依此进行有效开发。

其次，模型与实现过程以及技术环境间的互动反馈机制缺失。现实中，模型设计与具体技术实现应当是相互影响、密切联动的，但实际情况却好似两者在各自的世界里各行其是。举例来说，开发人员在实际操作中发现模型某部分在当前业务平台上运行效率极低，然而从发现问题到架构师全面了解到这一情况，竟耗去了数月之久。令人惋惜的是，待问题全貌浮出水面时，开发人员已自行完成了软件的开发工作，这套软件完全脱离了原有模型的框架，即便在尚存使用模型的部分，也只是将其简化为单纯的数据结构。面对这样的境况，开发人员虽对模型有所诟病，却也是无奈之举，毕竟他们不愿再冒险接受“象牙塔”中架构师的远程指挥，而选择脚踏实地解决问题。

二、设计贴合实际的模型

在软件的世界里，一个优秀的领域模型就像是一位经验丰富的向导，带领开发人员在复杂系统的密林中找到前进的道路。但是，如果这位向导只是纸上谈兵，对实际地形一无所知，那他的地图也就只能是一张废纸。因此，我们的模型必须与现实世界的代码紧密相连，否则它们就像是那些脱离现实的乌托邦，看似美好却无法触及。

想象一下，如果我们的程序设计和核心部分与领域模型毫无关联，那么这个模型就像是一座空中楼阁，虽然高耸入云，却无法为我们的软件开发提供坚实的基础。这样的模型不仅无法保证软件的正确性，反而会让我们的项目陷入困境。同时，过于复杂的模型和设计功能对应关系就像是一团乱麻，难以理清，当设计发生改变时，这样的关系更是难以维护。

在分析和设计之间，我们不能有鸿沟。分析工作要深入挖掘领域的基础概念，用简洁明了的方式表达出来；而设计工作则需要确定一套能够由项目中的编程工具创建的组件，让项目在目标部署环境中高效运行，并解决实际问题。这样，我们的模型才能够成为连接分析与设计的桥梁，而不是隔阂。

模型驱动设计（Model-Driven Design）的理念就是将分析模型和程序设计紧密结合，寻求一种能够满足双方需求的单一模型。在这个模型中，每个程序设计对象都应反映模型中描述的概念，这就要求我们在选择模型时要有更高的标准，因为它必须满足两种完全不同的目标。

抽象领域的方法有很多，解决问题的设计也千变万化。但我们不能因为技术考虑而牺牲分析的功能，也不能接受那些只反映了领域概念却舍弃了软件设计原则的拙劣设计。我们需要的是一种在分析和程序设计阶段都能发挥良好作用的模型。如果模型在实现层面显得不实用，我们必须重新设计它；如果模型无法忠实地描述领域的关键概念，我们同样需要重新设计它。这样，建模和程序设计就结合为一个统一的迭代开发过程。

在这个过程中，我们不仅要确保软件系统的各个部分设计能够忠实地反映领域模型，还要反复检查和修改模型，以便软件能够更自然地实现模型。即使我们想要模型反映出更深层次的领域概念，也应如此。我们需要的模型不仅要满足这两种需求，还要能够支持健壮的团队通用语言（Ubiquitous Language），让我们从模型中获取用于程序设计和基本职责分配的术语。

让程序代码成为模型的表达，代码的改变可能意味着模型的改变，这种影响必将波及接下来相应的项目活动。依赖模型的实现通常需要支持建模范式的软件开发工具和语言，比如面向对象的编程。这样，我们的模型才能真正成为指导我们前进的灯塔，照亮软件开发的道路。

---