大厂工作的跨域架构师，最好掌握这4个原则

今天学习的主要内容如下：

• 什么是跨域架构师，在职责上跟单域架构师有什么区别？

• 跨域架构师的勇气重要，还是技术重要？如何面对多领域之间的冲突，又如何解决冲突？

• 我是一名跨域架构师，可以告诉我有哪些基本建议和原则？

1、什么是跨域架构师。你看这个图，在领域拆分之前，人、系统、机器都在一个团队，只有一个管理者，这个叫单域，团队里面的架构师叫单域架构师。

图自https://time.geekbang.org/column/article/521463

反之，右边的组织关系中。人、系统、机器分别处在不同的团队中，有多个管理者，负责多个团队业务领域的架构师叫跨域架构师。

举个例子，一个大公司的BU会有多个产品线，每条产品线都有对应的产品经理。一个产品经理，往往会对应一个或者多个研发经理。一个研发经理负责一个研发领域，还会带领一个研发团队。一个研发团队有多个程序员。一名跨域架构师对应多个研发经理。

2、跨域架构师比单域架构师牛吗，回忆一下架构师的职责：“软件架构师就是为相对复杂的业务定义并引导实施一个结构化软件方案的能力，其中结构化，代表这个软件在其涉及范围内的设计理念、代码结构、实现方式上是同质的。”

这里的同质，该怎么理解。代码结构要遵循你的设计理念，实现方式要能落地代码结构，通俗些讲，设计什么样，实现就该什么样。反之，就不是同质。

结合上述架构师的职责，假设一下，如果你现在正负责多个领域的软件架构，而每个领域都有对应的研发经理，甚至领域内还有对应的单域架构师。试问，为什么这些领域的设计理念、代码结构和实现方式是处处一致的呢？

生产实际中，每个领域都有自己的领域目标、挑战、需求优先级、相对独立的工作环境。领域之间的设计理念也不一致。正如先前所讲，单域内的架构设计理念、代码结构、实现方式需要一致。跨域之间也需要一致，比如订单域有一个SOA层，依赖订单域的商详也有一个SOA层，那么这两个SOA层是不是冗余的呢。这个就需要跨域架构师来判断了，也会比较困难。

现在你知道跨域架构师的挑战了吧：“要持续抵抗天然的熵增，将多个子领域中不同的设计理念、代码结构和实现方式，往同质的方向上进行整合。”

你说跨域架构师牛不牛呢。

3、从一个线上事故说起。上一篇文章我们讲了一个背锅的故事。最后是架构师背的锅。

产生线上问题的原因，只有两个，一个是管理问题，一个是技术架构问题。而这个线上事故，既有管理的问题，也有技术架构的问题。

订单、支付、资金这样的业务团队，能不能不拆，这是一个平衡的问题。大单体和微服务之间的平衡。大单体在决策上可能实现上行下一，但也带来版本迭代慢，发布效率低下等问题。微服务当然有它的优势，比如执行效率快等。但也带来了这种协作沟通的问题。

公司成长，达到一定的体量，就会有多个微服务，多个领域，多个跨领域协作的团队。在大厂里尤甚，仔细想一想，这样做是必然的，大了就要拆，多了就要分。这块可以结合康威定律来理解。

所以，我们不会因为有这样跨领域协作的问题，从而倒退到原始组织的状态去。既然组织上不能返回大一统，那就尝试从技术架构上去解决。

就需要跨域架构师。

4、跨域架构师必备的四个要求。你若是一名跨域架构师，在生产实际中该怎么发挥你的水平呢。

1、在直接修复一个大BUG，和找到一个最优解之间，要选择后者。

2、跨域架构师的存在就是协调子域之间的决策、执行和沟通，从而平衡全局结构化和局部个性化之间的冲突，最终最大化全局目标的实现。

3、跨域架构师千万不能充当和事老。

4、要具备解决跨领域冲突的的能力和勇气，其中勇气有时候更重要。

今年9月5日，我在QCon大会性能优化主题中，也讲到了关于架构师，及团队文化冲突的内容。如有兴趣索取完整PPT，请加微信：wangxindong2015，备注PPT。

参考学习资料：郭东白老师的架构课。