以前在博客里也谈过架构设计问题，但只是一个一个的问题解决方式，缺乏真正面向现实的观点，自己曾经在电面中被问过这个问题，这个问题不好答，因为电面中也不知道问问题的人有几斤水，谈那些架构设计理论容易对牛弹琴，我越来月发现技术圈的很多人是不看书的。当然也是自己在这方面的总结反思不够，缺乏一个真正属于自己的实际问题角度去谈这个问题，这方面比较完善的架构设计理论应该是那本DDD书《领域驱动设计》，要看这本书，首先得过OOAD的关，在这个架构设计学习序列，DDD是中间一个环节，但给面试人讲这个，万一人家没看过就惨了，要讲肯定要讲自己的东西，那个时候的自己哪，觉得按照这些逻辑理性的理论一步一步走就行了，业务分析总没有技术设施层那么硬技术可炫，也没啥可讲的。最近这一段时间，接触了一些团队和人，发现这个观点是是小看了业务应用架构个问题在实际项目中被忽视的程度，所谓对比出真章，业务应用架构在实际项目中真正的有这么几个问题：1、领域建模还在简单的ER层面，对比DDD的领域建模的精细程度，有些人所持的ER观点非常简陋，根本没法建立真正高弹性的业务模型，这个建模的过程真正出现的问题，是人们对于一些不可见抽象概念的发掘能力不够，或者说根本就无法接受那种建模方式。第二个问题，建模容易被实现上弊病打乱，本来应该由业务需求向技术设施层逐渐自顶向下的建模过程，容易因为受技术设施层的掣肘，或者建模思考的懒惰，而采取一些勉强或者凑活的手段来解决问题。3、有些技术设施不是用了就高大上，任何一个手段都有它的应用情景和应用方式，凑积木一样在项目中使用，不一定出来Nice的结构。4、产品业务和技术的脱节，中国出了一个产品大神：张小龙，所谓以史证经：看观点不如学历史，很多人在读张小龙的那些XX观点的时候，却忽视了一个起码的现实，他坚持做了N多年的Foxmail，微信只是一次厚积薄发而已。很多小孩认为蜻蜓点水一下，都可以成为产品经理，重现神迹，这是错误的观点。产品在走第一步时，应该想好后续的步怎么走得顺啊，有些产品先给自己的项目上个一圈围墙和无数的坑，等到运行形势逼得不行了，又拆围墙再平坑，不要以为这只是给了技术更多的工作量而已，真正倒霉是这个产品项目，产品的发展和进化被上了无数的阻力。产品实现无法掌控的话，运营只不过是水中月，镜中花。