在给客户做了很多次领域驱动设计工作坊与研究了一些企业架构框架之后，我逐渐发现，对于一个架构师来说，有两个东西是最重要的，不是抽象能力，不是写PPT的能力，他雨是基本能力了。我这里说的是两个思维范式，一个是一分为二，另一个是合二为一。

一分为二

      先说一分为二。这里的二只是一个虚数，可以是一分为三，一分为四，也可以是一分为多。它有两个层面的意思，关注点分离与正反面思考。

       第一个层面是思考层面的关注点分离。人脑的思考负载是承受不了整个非常复杂的领域的，必须得把它拆分，同时间只思考其中一个方面，别的方面先忽略掉，不然就会陷入思考瘫痪的情况，无从下手。基于事件风暴来开展领域驱动设计，肯定也是基于每一个业务场景来做的，不可能同时做，我也不知道怎么同时做。
       同时，还要关注你所应该关注的。例如，在做ES过程中，往往会遇到某些事件会跟第三方系统或者是人的交互，客户就会问需不需要把第三方系统和人的具体事件也识别出来，我一般说不需要，因为那不是你的系统所需要关注的，实际上你也关注不了，别人会做什么你怎么知道呢?我们要做的是清晰界定系统的边界事件，这就足够了。这同样是关注点分离的思想。
       思考层面的关注点分离必然会导致最后架构设计上的职责分离。架构上的职责分离，就是指系统的分层，分治，其实就是老生常谈的高内聚。DDD里面，战术层面识别聚合，战略层面划分子域与限界上下文，无不是为了追求架构设计上的分层，分治。至于职责分离能够做到什么程度，这就需要不断的练习，积累经验了。

       第二个层面是正反向思考。最近发现一个比较有意思的现象。当有一篇公众号文章从正面把一件事物捧上天时，不过几天立刻就会有另外一个公众号发一篇文章从反面把这件事批得一无是处。举个最近的比较典型的两篇文章，一篇是《在中国，反抗应试教育的人，是真蠢》，另一篇《日本一位诺奖得主:东亚教育是在浪费时间》。有兴趣的同学可以搜索来读一下。一篇把中国应试教育捧上天，另一篇把中国应试教育踩落地。两篇文章谁对谁错呢?我说两篇都对，但都只看到了一面。比较合理的做法应该是从正反两个方面都思考应试教育的优缺点。这些明显有带节奏倾向的公众号文章越来越多，而且越来越有迷惑性，让人难以分辨。而这种以偏概全的做法在软件开发领域也经常碰到，最典型的例子莫过于微服务。
       这几年微服务架构可以说非常火热，很多人言必称微服务。刚开始的时候很多人写了很多文章不断吹嘘微服务架构比单体架构优越，绝口不谈微服务所带来的挑战，以至于很多人开发一个非常简单的系统也一定要赶上微服务的潮流。然而一开始开发后就叫苦连天。后面慢慢的才有一些人开始写文章批判微服务架构。这里不过多的讨论微服务架构的优劣，只是想说明这些无脑带节奏的行为其实都是不负责任的，往往都是带有商业目的。作为一名架构师，应该具备独立地从正反两个方向思考的能力，并时常保持警惕，严防有所企图者对某一事物的单方面吹嘘。

合二为一

       说完一分为二，现在说一下合二为一。这里的二也是个虚数，可以是合三为一，也可以是合多为一。
       合二为一的核心原则是“平衡”二字。我经常跟别人说，架构无他，唯独“平衡”二字。作为架构师，追求的是基于此时此地此况，综合考虑的最优解，而不是完美解。完美解并不存在，所有的解都是妥协的结果。举个例子，我们都知道两个上下文如果出现循环引用，意味着可能它们之间关系过于紧密，可以考虑合并，或者把导致循环引用的那部分抽出来单独作为一个上下文。但是如果它们之间有一个是第三方系统，那合并的做法就走不通了。那是不是一定要把那部分抽离呢?这个时候就要一分为二了，不能只看到正面的优点，还要想想反面的缺点，求得一个“平衡”的最优解。
       合二为一的思维模式在企业架构里面尤为重要。――例如在TOGAF中，把企业架构分为业务架构、数据架构、应用架构和技术架构四个层面，四个层面不是独立的，而是互相紧密联系和约束，统一形成一个完整的企业架构;而且，TOGAF还提出了视角与视点的概念，即认为即使是同一层面，不同的利益关系人从不同的角度观看架构，看到的东西是不一样的。例如，同样是技术架构，软件开发者看到的是系统逻辑架构，运维人员看到的是系统的部署架构，系统管理员看到的是基础设施架构。FEA的五大参考参考模型，DoDAF的八大视图，其实说的都是从不同的视角观看企业架构。这就要求企业架构师在给企业建模时，必须通盘考虑，谋求各个干系人的利益最大化。
       分析和看待问题时一分为二，必然要求我们在解决问题时合二为一。不然，我们解决问题的方法绝对是有问题的,以偏概全的情况大概率就会出现了。
       最后说一下“拍板”的问题。人思考的角度一多，就会容易出现模凌两可，做决策时犹豫不决的情况。我自己经常也是这样，说的好听叫谨慎，不好听叫多虑。怎么拿捏这个度其实也是一种“平衡”。另外一个思考的角度是承认架构是可以演变的，一时的决策并不是那么的重要，保持架构的持续演化才是最重要的。这个就是演进式架构的思想，是面向失败的架构。但是话又说回来，这又会是另一个“微服务”糖衣炮弹吗?