软件架构师类型

作者 / 以码为梯

排版 / 以码为梯

文章字数 / 1886

如何成为架构师系列文章（译文）的第三篇，欢迎转发、评论、收藏

在每个领域中都会有不同的专业。比如，在医学方面，我们有外科、心脏病学、眼科和许多其他领域；

当一个领域的知识量超过合理限度时，专业化就变成了必要的。由于软件架构囊括了大量的知识，因此必须减少人员的职责以提升生产力。因此，也可以将软件架构师分为不同的类型。

架构师类型

系统架构师（System architect）

解决方案架构师（Solution architect）

企业架构师（Enterprise architect）

领域架构师

我经常会听到一个问题，在移动开发领域是否存在架构师？这个问题产生了很多的共鸣以至于难以给出一个合理的答案。是否存在一个架构师只懂JavaEE技术栈或者只懂.NET技术栈？这样的专家该怎么称呼？是称为技术经理还是其他的什么？

对于这个问题的答案，在我的职业生涯中，有过几次改变。在我跟专业性很强的领域担任架构师的专家沟通的过程中，他们都是给出各种论据来证明他们所处位置的价值。也有一些人说，这毫无意义，对于只懂一个技术栈的专家，你可以称呼他任何职位，但是就是不能称他为架构师。

考虑这样一种情况，一家三人创业公司有一位 CEO（chief executive officer首席执行官）、一位 CTO（chief technical officer首席技术官）和一位 CMO（chief marketing officer首席营销官）。但是是否有一个技术官的职位给开发人员，或者一个营销官的职位给销售人员？这些头衔是一些虚无的东西还是真实需要？

其实，说到底对于这些职位的称呼是次要的，而处于该职位的人的职责才是最重要的。

如果一个项目由一个或多个平台组成，每个平台都需要一个专家来担任各自的领域架构师，这些领域架构师的职责如下：

确认项目相关的利益相关者。

需要注意的是领域架构师需要选择对平台有影响的利益相关者，并跟他们一起共事。

确认商业需求和利益相关者的需求。

如果架构师找到了特定于平台的利益相关者，那他应该找到相关需求以及领域相关的限制。

根据收到的需求设计整个系统。

对一个领域架构师来说，重要的不是设计整个系统，而是将平台整合到项目中去。并且考虑那些会影响平台的组件之间的交互方式。

选择实现每个组件的技术和组件之间联通的方式。

与更高级别的架构师不同，领域架构师通常对他的平台的应用程序技术选择具有最重要的影响。比如，在移动开发中，架构师需要考虑项目中采取哪种测试，是否需要使用代码生成，如何组织服务层和持久层，使用哪一种架构模式以及这种架构模式对项目来说是必须的。

编写项目文档并维护。

即使在一个平台里面，如果存在一个架构，那么它应该被记录下来。在书籍《Software Architecture in Practice》中写道，如果架构没有被记录，那么它就不是一个架构。在移动端开发中，架构可以包含数据库设计、网络交互图、类图等等。

创建公司内部的统一开发标准。

这一点特别适合领域架构师，因为所有标准通常都是为特定平台开发的。

在系统迭代的时候控制架构。

领域架构师必须控制整个产品开发周期，而且必须是最接近平台技术组件的人。同时，从整体上看，架构师对特定平台上的产品质量负全部责任。

因此，存在大量不同类型的领域架构师：

Some types of domain architects

图片只展示了其中的一小部分。实际上，它们还有很多，还有各种技术栈。

另一方面，只有当相应的职责很明显时，才需要增加架构师的职位。

如果你有一个包含一个平台和两个开发人员的项目，那么增加一个架构师的职位是多余的，其中一个开发人员可以履行这些职责。

从一种类型的架构师成长为另一种

让我们用T型模型来探讨这个话题。T型模型假设专家有纵向和横向两个发展方向。纵向发展的意思是在提升专业内的技能，更深入地学习相关知识。横向发展的意思是了解多个领域、多个技术栈，有更广的技术视野。通过这种方式也可以随时了解员工当前的知识和经验水平。

如果开发者在同一个技术栈内部，学习新的框架、语言和开发工作，就是纵向的发展。但是作为架构师，不能只在一个技术栈内深耕，还需要有更广的技术栈。

T-Shaped skills of an architect

同时，架构师的成长与他拥有理论和主要实践专业知识的平台数量密切相关，也与他了解的学科领域数量密切相关。架构师职业发展的目标是形成“m”——多平台和多领域专家。

希望这篇译文（文章）可以得到大家地喜欢。

来源：以码为梯