不久前，在一个并不遥远的IT世界里，架构师的角色被认为是不必要的。开发人员精通他们在大学数据库和网页设计课上学到的三层架构和ERD。精通对象建模、UML图解和文档的架构师只是臃肿的，是已逝的瀑布时代的遗物。
这在云计算时代已经完全改变了。现代的架构师不是画类图，而是制作使微服务之间相互作用的顺序和步骤。
分布式微服务系统架构的第一步是从事件风暴开始的。这是由Alberto Brandolini推广的一种设计思维方法。它是一个协作过程，用于发现系统的领域，并产生微服务的范围和边界。微服务的术语在很大程度上借鉴了Eric Evans的领域驱动设计软件方法，其核心是业务领域。这是一个需要实现的应用问题空间或业务功能。一个微服务的范围就是这个单一的领域。
让我们把话说清楚，领域驱动设计和事件风暴是架构性的，而不是功能性的。一个功能分析员虽然是业务领域的专家，但却缺乏技术上的细微差别来产生适当的范围和微服务的相互作用。然而，他们将与架构师合作。
在光谱的另一端，软件开发人员将更关注技术范围，并看到业务流程。在微服务的世界里，没有适当设计的牛仔编码只会产生一个分布式的单片机。大多数企业今天开始他们的云计算之旅，将永远被网络延迟、复杂性和（上帝保佑）意外的数据损失所创伤，这些都是由设计不良的分布式系统引起的。
敏捷原则仍然适用。全面的文档是不需要的。相反，一个微服务和能力的清单将有助于计划冲刺。微服务的划分可能会有错误，所以变化可以在途中发生。但是，通过思考设计和它应该如何工作，将使实施时的系统更加乖巧。
人和关系是这个过程的核心。架构师很少在孤立的环境中工作。她必须与客户的领域专家、开发团队和项目经理互动。策略和适当的政治敏锐性是对她的角色的一个硬性 "软技能 "要求。
从面向对象设计的角度来看，架构师在编码开始之前应该是中立的。虽然Eric Evans的书重在面向对象的原则，但必须了解他是在前SOA时代写的，更不用说微服务时代了。对微服务进行建模，聚合其实体、值对象和关系是高级开发人员或团队领导的任务。而他们的模型将是他们的代码。架构师将对微服务之间的合同进行建模。他们将使用REST（OpenAPI）合同（或gRPC）进行同步调用，并通过Kafkaesque事件进行异步调用的事件规范。
合同可以改变，整个开发过程中的事件也可以改变。没有什么是一成不变的。但是，整体的调用顺序以及一个服务如何与下一个服务对话以提供功能，需要一个整体的系统视图。一些在微服务上工作的开发者将无法看到或考虑到在他们领域的杂草中的东西。
但是微服务是自成一体的...
"正确的设计意味着每个微服务都是自成一体的，不管其他服务做什么，都要做自己的事情"，或者这样认为。这是正确的，但业务功能往往会跨越多个服务。因此，需要这个能看到大局并能协调它们的人。
从这个角度来看，当前端沿着微型前端的新生模式划分时，也同样适用。当你想协调多件软件的时候，就是你开始需要一个架构师的时候。
在所有这些理论化的过程中，架构师还应该写出概念证明或棘手的代码。俗话说，"代码赢得争论"，所以适当的编码能力是一个硬性要求。不画框，不知道它们的意思。她还可以专注于测试代码或健身功能，以确保软件按预期运行。当然，她还应该在实践层面上熟悉DevOps和承载代码的云基础设施。
当年的情况要简单得多，一个开发人员就可以构建整个单体架构并让一百个用户入驻。即使在今天，一个好的软件开发团队也足够了。他们可以解决大多数问题，但他们会在不断地编写和重写、分割和组合他们的微服务时增加项目的价格标签。因此，对于今天迎合数百万用户的复杂系统，软件架构师是成功的必要条件。
面向对象的象牙塔架构师已经死了！分布式系统架构师万岁！