软件架构设计服务于软件的开发，从最开始的【传统开发模式】到目前很热的快速开发，有以下发展过程：

• 初期瀑布模型的不完善，延伸出修补需求不完善、风险不可控的螺旋模型，这同时也吸收了轻量快速开发的元素。
• 漫长的开发过程，催生了【快速应用开发方法论】，而有了迭代开发、敏捷开发、ddd、微服务等轻量模型。

软件设计的本质是为了企业服务，初期从无到1诞生了很多软件设计模式，zachman模型的诞生才有了企业架构服务的理念，到1995年togaf的出现才有了具体的构建方法，发展至今已经到了v9版本，仍然很重，潍柴科技项目有用到了混合实施模式。

敏捷开发、ddd和微服务是架构的组合拳，在服务划分上面提供了很好的补充，但项目初期微服务还没有比较好的设计思路，需要对业务很精炼才能做到。

EBA 并非“瀑布模型”，它是一个对企业当前状态的刻画过程，是一种快照，是寻找企业战略落地措施的方法。

中台并没有像 EBA 那样给出一个明确的设计过程和方法，所以，分析也很难做的更深入，这并不是对着几张漂亮的架构图就可以做的比较

软件工程

维基定义： 究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

也就说，包含了软件的定义、开发、运维性维护全生命过程。

软件工程包括两种构面：软件开发技术和软件项目管理。

常见术语

软件工程师：对应用软件创造软件的人们的统称，软件工程师按照所处的领域不同可以分为

• 系统分析师
• 系统架构师
• 200-后端和后端工程师
• 程序员
• 测试工程师
• 用户界面设计师等。

软件开发（英语：Software development）是根据用户要求建造出软件系统或者系统中软件部分的一个产品开发的系统工程，包括

• 需求获取，包括需求来源和获取需求的技术，涉及软件开发人员如何与包括客户在内的各方干系人建立有效的沟通,以来获取各方对软件的要求、期望、限制等等。也称为“需求发现”、“需求获得”
  • 在不少Scrum的实践中，将用户故事作为需求获取的产物，放到产品待办列表中。
  • 称为客户需求，经简要提炼的客户需求，焦点是捕获正确的市场导向，或者就大致功能范围得到客户的初步认可。
  • 称为原始需求，直接采用客户和干系人的语言，在尽量澄清真实意思的情况下，不加分析的，收集原始信息。
• 需求分析，理想的需求要整理成文件、可以执行、量测、测试、追踪、和识别到的商业的需求或机会有关，而且要有系统设计的相关设计细节。
• 设计
• 开发规划
• 编程实现
• 软件测试
• 版本控制

软件开发方法论：软件开发的指导思想，属于“法”的层面，常见的方法论如下：

• RUP
• 敏捷软件开发

软件开发模型：软件开发的实际操作方法，常见套路，属于“术”的层面，常见的开发模型如下：

• 瀑布模型
  • 传统瀑布模型
  • V模型
• 螺旋模型
• 迭代模型

软件工程与企业架构的发展概要

资料来源于： 中台辨析：架构的演进趋势_架构_钰湚—付晓岩_InfoQ精选文章

电脑的出现，让科技革命对软件的爆发式增长有了极高的要求，因此诞生出如何科学快速产出维护软件所对应的软件工程科学，主要的里程碑如下：

（一）懵懂初期，无工程、无架构，硬件发展不足，主要在实验室中运行。

（二）传统开发，主要代表【瀑布模型】和zachman模型

1970 年，Winston Royce 在《大型软件系统开发的管理》一文中，提出了“瀑布模型”，将开发分成如图 1 所示的 7 个明确的阶段：

Royce 认为这是个有风险的开发过程，并提出了 5 个修改建议，包括在分析阶段之前增加一个在信息不足条件下的预设计、开发过程中增加客户参与等，市场大量将这个模型作为开发的标准过程，的分析阶段也就包括了架构设计工作，逐渐又被细分为概要设计和详细设计。这时期的架构设计主要还是针对软件设计，还没有发展出成形的企业架构理论。

随着人们对软件设计工作认识的不断深入，大型软件设计与企业管理的关系越来越紧密，这也体现了人们对软件设计的本质性目标——为企业服务的认知。基于此，1987 年 Zachman 提出了首个较为完整的企业架构模型，该模型按照“5W1H”，即 What（数据）、How（功能）、Where（网络）、Who（角色）、When（时间）、Why（动机）6 个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统 6 个层次，将企业架构分成 36 个组成部分，描述了一个完整的企业架构要考虑的内容。

这个架构设计方法论已经将系统设计应支持企业经营管理目标的要求表达出来，但是该模型的一个不足是 Zachman 并没有给出一个详细的构建方法。

（三）成熟的进步：螺旋模型和 TOGAF

1988 年，软件工程上又一个里程碑式的方法诞生了，Barry Boehm 提出了“螺旋模型”，该模型如图 2 所示：

螺旋模型通过持续对原型进行验证式、增量交付的方式，弥补“瀑布模型”在需求管理方面不足，是一种对需求的渐进式探索，也加强了对项目风险的管理。

随着信息化程度的加深，企业越发认识到将 IT 融入企业管理的重要性，IT 人员也意识到与业务结合的重要性，于是，1995 年 TOGAF（The Open Group Architecture Framework ，开放组体系结构框架）应运而生，业务架构的概念也被明确提出来。TOGAF 认为企业架构分为业务架构和 IT 架构两大部分，业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容，业务架构再作用于 IT 实现。TOGAF 的设计交付物如表 2 所示：

可以看出，到 TOGAF 时代，在内容上，企业架构和业务架构发展的已经较为完善了；在工艺上，TOGAF 也有明确的操作要求，也正是因为有详细的要求，TOGAF 被公认的缺点之一就是太“重”，有点像是架构领域的“瀑布模型”。

从 Zachman 到 TOGAF，尽管理论日臻成熟，但是企业架构设计与实际开发过程之间的结合一直不是很好，更像是在两条线上发展，表面看起来，Zachman 模型似乎还能跟“瀑布模型”走得到一起，毕竟二者都被认为是“漫长”的，但大部分开发实际上在这个时期都是沿着“竖井式”的道路在走，仍旧缺乏对企业级设计的关心。至于 TOGAF，它跟螺旋模型、迭代模型之间在实操上有不易结合之嫌，恐怕不少企业接受了应用 TOGAF 思路的咨询方案，却在实施过程中将其束之高阁了。尽管如此，TOGAF 对推动企业架构发展的作用仍是非常大的。

（四）对更快的探索：敏捷开发、DDD 和微服务

对效率的探索涌现出了更多的软件工程方法、设计方法，不同方法间逐渐形成组合，从单一方法到“组合拳”也是一个很有意思的过程。

不满足于软件工程的进步，90 年代，敏捷开发的思路开始出现。2001 年，在美国犹他州雪鸟滑雪胜地，敏捷方法发起者组织敏捷聚会并起草大名鼎鼎的《敏捷宣言》，“敏捷”开发也在这次聚会上正式定名。虽然目前对敏捷开发的认识还不是很一致，但大体上的开发流程，可以在网上找到很多类似图 3 的介绍：

敏捷开发的矛头可谓直指“瀑布模型”，大多数讲敏捷开发的书几乎都以此开头。笔者并非一个敏捷实践者，因此也无法深入讨论这一方法的优缺点，但是从对其实现过程的介绍来看，企业架构的设计显然没有包含在敏捷过程中，敏捷强调的是产品和用户维度，而且敏捷的“轻文档”理念与企业架构已有的“重文档”方法之间也是有矛盾的。

由于研究的人很多，敏捷开发在软件过程管理和软件设计方面都有较快发展。尽管有人质疑其效果，但是据称全球排名第 11 的资产管理公司——荷兰国际集团（ING）是在全公司推行敏捷开发的，该公司拥有员工 113,000 人，在全球 50 个国家为 6 千多万客户提供金融服务。

除了对过程的加速，架构设计方法本身也有创新。2003 年，Eric Evans 提出了 DDD，也即领域驱动设计方法，该方法的特点是在需求分析、软件设计方面的一体化实现，通过领域模型直接形成可以指导到“类”设计的软件架构模型。但是 DDD 明显只是一个软件架构设计方法，而非企业架构设计，并且，DDD 领域的大师级人物 Vaughn Vernon 认为企业级是无法从顶层直接设计的，只能在领域建模完成后，逐个领域地进行尝试性融合。Eric Evans 也在其书的结尾对“总体规划”方法表示了一种委婉的不信任。DDD 最经典的架构图如图 4 和图 5 所示：

Eric Evans 曾提出该方法主要面向敏捷过程，二者其实在方法层面有相似之处，都强调快速由需求进入开发过程，也都注重对模式的运用。但是因为 DDD 方法掌握起来有一定难度，因此并没有真的随着敏捷开发“火”起来，倒是借了另一种架构风格的“东风”，微服务。

微服务最早由 Martin Fowler 与 James Lewis 于 2014 年共同提出，微服务架构风格注重用具备独立数据库的微服务来替代原有的单体应用设计方式，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是 Restful API。这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。从理念上看，极具灵活性、快速响应能力、可复用性和扩展性，案例上更是有传奇公司 Netflix 做标杆。

但是这种架构风格并没有很好地处理它的前身 SOA 遗留的问题，就是如何确定服务的颗粒度，于是，不温不火快 10 年的 DDD 派上用场了。DDD 这种可以直接按照限界上下文导出数据和行为相结合的设计结果的方法，很适合推微服务一把。Chris Richardson 在其著作《微服务架构设计模式》一书中就专门花了两章来介绍 DDD 与微服务的结合。

在对更快的探索中，敏捷开发、DDD 和微服务提供了一种包括软件过程、架构设计和工程实现在内的“组合拳”，当然，这并不意味着所有企业都要这么用，只是一种参考而已。此外，求快的同时，这些方法也都欠缺对企业架构的关注，它们都是可以提升 IT 开发效能的有力工具，但是，在 To B 端，仍需要一种可以面向企业级能力建设的方法作为总体导引。

敏捷开发与瀑布开发的区别

瀑布开发

瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型软件开发按工厂流水线形式分层设计。

这是鸿蒙期诞生的里程碑开发方法论，收到了市场追捧，但因过程漫长、需求和风险不够重视，而被诟病，虽然作者一开始就意识到了。

瀑布模型的特点：

1、强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。

2、 没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应，瀑布就意味着没有回头路。

3、管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。瀑布模型的用户很多，也有一些反对的意见：

第一、瀑布模型不适合客户需求不断变化的软件开发，后期的需求更改成本是开始的10倍基数。

第二、瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣。

敏捷开发

极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。

敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。

敏捷开发集成了新型开发模式的共同特点

它重点强调：

1.敏捷就是“快”。快才可以适应目前社会的快节奏，要快就要发挥个人的个性思维多一些个性思维的增多。

2.客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求。

3.强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。

4.设计周密是为了最终软件的质量，但不表明设计比实现更重要。

5.迭代。软件的功能是客户的需求，界面的操作是客户的“感觉”。对迭代的强调是缩短了软件版本的周期。

6.小版本。快速功能的展现，看似简单，但对于复杂的客户需求合理地分割与总体上的统一，要很好地二者兼顾是不容易的。

项目开发中的常见模型

瀑布模型、迭代模型、增量模型、原型模型，是项目管理常见的四种模型。每种模型都有其优缺点和适用的项目类型。项目经理针对不同的项目用对模型，才能起到事半功倍的作用。

各模型项目特点：

瀑布模型——文档驱动型

迭代模型——风险驱动型

增量模型——任务驱动型

原型模型——需求驱动型

这里有参考： (5条消息) 软件工程方法论对我们经软件开发有多大用处？_南风如意的博客-CSDN博客

(5条消息) 详谈软件工程之软件开发方法（一）_华星详谈的博客-CSDN博客_软件开发方法

01 瀑布模型

用瀑布模型做项目就像古代匠雕刻玉石，先有完整的设计图，然后按部就班往前推进，中间不能出一点差错，追求的是“一次成型”。

这就是瀑布模型，最基本也最常用的一种项目管理模型，又称线性模型。

采用瀑布模型的项目依照该模型选定的阶段顺序进行，每一个阶段的工作产品都是下一个阶段工作的输入，每一个阶段只有在上一个阶段通过检查，确认完成后才开始新的阶段工作。

▲ 瀑布模型的思想示意图

瀑布模型的突出特征是文档驱动。从需求分析到系统维护，每一项活动的工作成果就是此项活动所产生的工作文档，以及在此基础上形成的产品。

瀑布模型最大的优点有两个：

1、每个阶段的开发质量都有保证，减少了返工。2、是文档细致，降低了沟通成本，有利于及早发现问题。

这就是开头说的雕刻玉石的步骤，有精细的设计图纸，每一步都不可行差踏错，因为一旦雕坏了，就得摔了玉重来。

这也正是瀑布模型的缺点：周期长，不易变更。

用户直到项目开发晚期才能了解产品的真实面貌和质量。这时候提出变更，成本会非常大。

适合采用瀑布模型的项目类型，通常是对用户需求非常明确的项目。同时还要求项目预算充足，人员齐备。

02 迭代模型

其实，迭代模型项目就是数个小而快的瀑布式项目组成的。

因为，每一次开发迭代都是一次完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。

每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

▲ 迭代模型的思想示意图

迭代模型沿着螺线进行若干次迭代，图中的四个象限代表了四个活动：制定计划、风险分析、实施工程、客户评估。

使用迭代模型进行软件开发，项目活动包含以下几个阶段：

1. 初始阶段为系统建立商业案例并确定项目的边界。2. 细化阶段细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。3. 构造阶段在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。4. 交付阶段交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。

▲ 迭代模型的几个阶段

迭代模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

因此，迭代模型的风险管理成本较高，在风险分析，进度管理方面，对项目组成员的要求也非常高。

选择迭代模型的项目，通常属于高风险项目，且需求不确定，用户能在整个开发过程中不同程度地参与。

03 增量模型

增量模型是通过对用户需求的判断，在定义了用户要求和系统需求,进行总体构架设计后，采用序列化地创建产品的方法进行开发的过程。

增量模型本质上是迭代的，但其强调：每一个增量均发布一个可操作产品。

增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。

▲ 增量模型的思想示意图

虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

增量模型有三大优点：

1、在达到初始需求之前可降低成本。2、可快速生产出可使用的系统。 3、能够有计划地管理技术风险。

但是，在开发过程中，需求的变化是不可避免的。

增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，导致软件过程的控制失去整体性。

增量模型的适用项目特点：

i. 用户核心需求非常清楚；ii. 项目人员不足；iii. 产品可以分割成不同的阶段分别完成

04 原型模型

原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发.

原型模型是一种用户需求驱动的方法。它能减少系统开发的风险，特别是在大型项目的开发中,由于对项目需求的分析难以一次完成，应用原型法效果更为明显。

▲ 原型模型的思想示意图

原型模型根据其最终保留情况分为非抛弃型和抛弃型两种：

非抛弃型原型：先根据用户的最主要的要求，开发出能实现系统最基本功能的一个原型，再根据用户对原型使用与评价的意见，反复修改完善原型，直到等到用户满意的最终系统为止。

抛弃型原型模型：一般用来描述和验证用户需求，可以采用与实际开发所不同的开发工具，建立模拟的数据库系统，从而达到与用户交流的最好效果。到用户需求确定之后即不再继续开发此原型。

这两者的目的、手段、结构各有不同。采取抛弃型原型模型往往是为了和用户更好地沟通，大家一定要注意区分。

原型模型适用的项目特点：

i 处理简单过程明确、涉及面窄的小型系统；ii 大型系统的需求阶段，用原型去跟用户交流，需求分析会更加明确和细化

写在最后

针对不同类型的项目。应选择什么样的开发模型，应从以下两方面进行慎重考虑：

i. 实施推广的难度

项目管理团队的管理能力和系统开发团队的技术能力决定了所选择开发模型的实施难度。选择一个适合项目团队特点的开发模型尤为重要。

ii. 项目管理的侧重点

项目不同，其侧重点也不同，如侧重于进度、质量、成本控制、风险管理等等。根据项目的侧重点，可以选择不同的开发模型。

再结合这些特点，选择最适合项目的开发模型，就能起到事半功倍的效果。

开发者眼中的“道、法、术、器

道：客户的核心诉求是道，如何让客户满意是道，客户沟通中的潜台词是道。

法：软件开发方法论是法，如成套的传统开发、快速开发。

术：软件开发的落地模型，经验证可靠、持久，如瀑布模型、敏捷开发模型、ddd、微服务、螺旋模型、喷泉模型等等。

器：开发用到的ide、脚手架、构建工具、第三方组件等等。