每个领域都有不同的专业。 比如医学方面有内科、心脏病学、眼科等等；
当某个领域的知识量超过合理限度时，专业化就变得必要。 由于软件架构包含大量知识，因此必须减少人类责任以提高生产力。 为此，软件架构师也可以分为不同的类型。
建筑师类型
系统架构师（Systemarchitect）
解决方案架构师（解决方案架构师）
企业架构师（企业架构师）
领域架构师
我经常看到一个问题，联通开发领域有架构师吗？ 这个问题引起了如此多的共鸣，以至于无法给出合理的答案。 有没有一个架构师只懂JavaEE技术栈或者只懂.NET技术栈？ 这样的专家应该受到怎样的表彰呢？ 是叫技术总监还是其他什么？
在我的职业生涯中，这个问题的答案已经改变了好几次。 在与专业领域的专家、同时也是建筑师的交流过程中，他们都给出了各种论据来证明自己立场的价值。 也有人表示，这没有意义。 对于一个只懂一种技术栈的专家，你可以尊称他为任何职位软件架构师培训视频，只是不能称他为架构师。
考虑这样一种情况：一家四人初创公司有一名 CEO（首席执行官）、一名 CTO（首席技术官）和一名 CMO（首席营销官）。 是否有针对开发人员的技术官职位，或者针对销售的营销官职位？ 这些头衔是虚无主义的还是真正的必需品？
但归根结底，对这一职位的尊重是次要的，担任该职位的人的职责才是最重要的。
如果一个项目由一个或多个平台组成，那么每个平台都需要一位专家作为自己的领域架构师。 这些领域架构师的职责如下：
确定与项目相关的利益相关者。
需要注意的是，领域架构师需要选择对平台有影响的利益相关者并与他们合作。
确定业务需求和利益相关者的需求。
如果架构师找到特定于平台的利益相关者，他应该找到相关的需求和领域相关的约束。
根据收到的要求设计整个系统。
对于领域架构师来说，重要的不是设计整个系统，而是将平台集成到项目中。 并考虑它们如何与平台的组件交互。
选择实现每个组件的技术以及在组件之间移动的方法。
与高级架构师不同，领域架构师通常对其平台的应用程序技术选择具有最重要的影响。 例如，在中国联通开发中，架构师需要考虑项目中采用什么样的测试，是否使用代码生成，如何组织服务层和持久层，使用哪种架构模式，而这些架构模式是项目所必需的。
编译和维护项目文档。
虽然在一个平台上，如果有框架，那么就应该记录下来。 《软件架构实践》一书中写道，如果架构没有文档化，那么它就不是架构。 在中国联通的开发中，架构可以包括数据库设计、网络交互图、类图等。
在公司内部建立统一的开发标准。
这非常适合领域架构师，因为所有标准一般都是针对特定平台开发的。
随着系统迭代控制架构。
领域架构师必须控制整个产品开发周期，并且必须是最接近平台技术组件的人。 同时，作为一个整体，架构师对特定平台上的产品质量负全部责任。
为此，有许多不同类型的领域架构师：
某些类型的领域架构师
图片只展示了其中的一小部分。 事实上软件架构师培训视频，它们还有更多，以及各种技术堆栈。
另一方面，只有当相应的责任很明显时，才有必要降低架构师的职位。
如果你的项目有一个平台和两个开发人员，那么放弃一个架构师的职位是多余的，由一个开发人员来履行这一职责。
从一种类型的建筑师成长为另一种类型的建筑师
让我们用 T 模型来说明这个主题。 T模型假设专家有两个发展方向，水平和垂直。 横向发展意味着提高专业技能，更深入地学习相关知识。 纵向发展意味着了解多个领域、多个技术栈，拥有更广阔的技术视角。 这些方法还可以跟踪员工当前的知识和经验水平。
如果开发者在同一个技术栈内学习新的框架、语言和开发工作，那就是横向开发。 而作为一名架构师，不能只专注于一个技术栈，还需要拥有更广泛的技术栈。
T型技能如此范建筑师
同时，一个建筑师的成长与他所拥有的理论和主要实践专业知识的平台数量以及所了解的学科领域的数量密切相关。 架构师职业发展的目标是培养“m”——多平台、多领域专家。
希望这篇翻译（文章）能被你喜欢。
