架构师需不需要懂业务？ 这个问题相信很多人都看到过。而且答案也很明显，架构师需要懂业务。至于为什么，那是各有各的说辞。这里我们从网上摘录一些供大家参考。

• 不懂业务的架构师就不存在

• 架构师应当是解决问题的人

• 不懂业务的架构师就相当于没读懂题目就开始解题

架构的意义

网上这种说法很多，也都很有道理。我们这里并不是去反驳这个观点的正确性。而是和大家一起探讨架构的业务属性。我们可能觉得架构的目的是设计出一个完美或者说是良好的结构，指导团队的开发。如果以这个准则来说，架构也太简单了，我们只需要用广为流传的设计或者业内成熟的设计就可以了。甚至在很多时候这个方式都是可行的，也没什么问题。但是最终我们会发现自己的业务改来改去，原来的一些设计也因为各种原因被不断修改，返工。我么本来完美的设计逐渐变得臃肿，复杂。最后被迫重新进行设计或者放弃设计。

这个原因就是因为我们在架构中常常忽略其业务属性，一个架构到后面最大的问题往往不是对于技术的错误评估，也不是设计上的不够完美。而是对于问题的错误理解。如果我们在一开始就没有理解我们要解决的问题，那么我们设计出来的东西也就走入了歧途。我们要知道的就是无论是架构还是编码，我们都是为了解决某个问题，可能是业务的需求，也可能是缩减成本。

所以现在 DDD（领域驱动设计）又再次出现在很多文章中，是因为随着架构的技术不断更迭，技术上的选型有很多可以参考或者借鉴的东西存在。这时候很多人才发现技术上的问题反而不是最大的问题，技术的改进并没有带来架构的门槛降低。没有理解业务的情况下，采用再先进的设计也不可避免的造成后期的返工和重构。

所以如果我们以后想要成为架构师，就先从理解问题和分析问题开始。即使我们是刚入门的程序员，离架构师还很远，我们依旧可以从日常的任务中培养理解和分析问题的能力，只有当你对你要解决的问题理解的深度和广度足够大，你就会发现有一个结构已经出现在你的脑海中，而这个结构就是所谓的架构。