几个值得探讨的问题

如何成为优秀的架构师？

架构师 = 技术大牛？
技术大牛是架构师的基本条件。
如何成为一个优秀的架构师？
只懂技术，不了解业务，永远成为不了优秀的架构师。
只有技术实现了业务需求、解决了业务痛点，才具有价值，才能让用户买单。

什么是业务架构师？

了解业务全链路，上下游，甚至能够影响业务发展走向。

架构师的本质

架构师，要能够将业务转换为技术，能合理运用技术支撑业务。
用新的技术解决新的问题，用合理的技术方案解决各种问题。不断学习，不断优化。让产品充满生命力。

如何成为一个顶级架构师？

对业务及其痛点有深刻的理解与思考，成为团队的定海神针、灵魂人物

分析业务流程
理解业务规则
挖掘业务痛点

能够将技术落地，产生业务价值

规划高远却落不了地
快速研发产生业务价值

关键难题

如何快速有效地学习业务领域知识
如何深入地理解与挖掘业务痛点
如何通过技术手段落地业务

为什么需要领域驱动设计

领域驱动设计越来越流行

越来越多的团队开始尝试 DDD
越来越多的面试开始问 DDD
越来越多微服务团队用 DDD 设计
越来越多团队用 DDD 建设中台
……

参考书籍：《领域驱动设计——软件核心复杂性应对之道》

系统越复杂，DDD 越有用。
以前业务简单，场景普通，用 DDD 反而增加了“复杂性”。
这也是为什么很早提出概念但现在才开始流行。

为什么需要领域驱动？

在新项目开发中起作用么？
在老项目维护中起作用么？
在技术架构演化中起作用么？

用领域驱动设计做新项目
DDD 领域驱动设计 - 图1
DDD 在新项目开发中不仅不会发挥出优势，反而很累赘。不如传统开发方式。

在老系统上不断迭代
最初的项目，功能简单，场景单一，可以按照传统开发方式快速迭代。
但是项目逐渐成熟，系统复杂度提升，不断的新需求和改动，导致维护越来越难。
所以这时候就通过领域驱动分析，对系统抽象出领域模型，降低复杂度。
未来的项目，业务不断迭代，市场激烈竞争，技术快速更新，系统变得庞大……
DDD 重构后才能继续做到快速迭代交付。

领域驱动的解决之道

微服务拆分原则，小而专，单一职责，建立在对于业务深刻的理解和拆分上。
微服务拆分又是基于领域驱动设计。
微服务架构 + 领域驱动设计。
引入领域驱动设计是为了降低系统复杂度，提高交付速度。
而这里其实是有一对矛盾存在的，当落地到编码的时候，微服务拆分能提升交付质量和效率，而引入领域驱动设计本身却增加了复杂度。
这个问题怎么解决呢？
底层架构团队。通过整洁架构，将复杂或者公共的逻辑下沉，封装到底层技术框架中，上层在进行领域驱动设计和微服务开发的时候，可以更关注业务落地，而降低技术实现的复杂度。