架构师浅谈

如何衡量架构师的价值？

我看过这么一个故事，大概意思是大家都赞扬扁鹊医术高明，扁鹊回答说他在他们家是医术最差的一位。他大哥医术最高明，能在重病还没有任何病痛迹象的时候解决掉，大家都不知道大哥的功劳。二哥医术第二，能在重病有一点点预兆的时候发现并解决病痛，所以大家对二哥的评价是只能治小病。扁鹊是在重病真正发作时才能发现并解决但他得到最高的赞誉。这个是不是也和架构师的情况很像呢？但是在实际工作中往往扁鹊们可以得到大家的赞扬，而大哥，二哥们却没有得到就有的待遇。如何让大哥，二哥们得到应有的待遇呢？做架构以后，我听得最多的是FDD,故障驱动设计，使得大家越来越倾向在出了问题后去解决问题，这样的现象我理解是架构师向现实的一种妥协，但不正确。

解决方案：

1、这个事情引申一下，个人认为是如何评价一个系统架构设计的优劣，就跟如何评估系统代码的优劣一样；需要一套不断进化的评估方法，代替时间的验证。

2、我认为衡量一个架构师可以从两个方面：能力和价值。能力可以制定一些行业标准和证书等。价值是架构师利用个人能力，给所在公司带来的实际价值。

3、我认为我们需要架构师类似商鞅变法，擅长发现问题创造新架构解决问题。更需要秦始皇这类架构师，能坚持在一样，把理想的制度和体系推广开来，统一六国。甚至是焚书坑儒。

敏捷项目中架构师的职责与定位是什么？

1.软件架构师需要躬身入局，从架构视角来关注系统整体结构而非仅仅是业务功能，以创建出一个更具备可修改性和可维护性的系统。

2.敏捷的核心要义需要被正确解读，而不仅仅是快速迭代，前期的整体设计阶段同样重要，需要参与者认真理解敏捷的实质而非表象。

3.敏捷中的架构重在演进而非一锤定音，架构师需要伴随项目进行架构的敏捷迭代。

DDD和敏捷能共处吗？如何共处？

问题描述：让我们先抛开康威定律来讨论这个问题，DDD最后要落地到Design的，而且是一个团队在做这个Design的，而敏捷要关注可用产品。在这个说短不短的Design下怎么出产品？

解决方案：

1.把设计成果也当作一种交付，产出"用户看得懂的设计文档"。整个设计过程可以敏捷

2.DDD并不是每个迭代都需要做很重事件风暴工作坊。在项目初期阶段是需要事件风暴工作坊来对齐业务和技术的认知，会耗费团队2-3天时间，但在后续迭代过程中，因为有了前期统一认识(统一语言)的基础，这个形式会简化很多，一个迭代事件风暴可能1-2小时就完成了。具体实践可用事件风暴工作坊代替需求