根据商品的使用价值理论，一个完整的软件产品必须解决某个领域特定的问题。据此，每个软件产品的架构就会呈现出独特的特征和关注点，比如手机终端的APP就会非常关心资源占用、能耗和UED体验等，而一款企业应用则会把快速实现商业逻辑作为首位，不会把能耗作为首要考量因素。即使针对同样的架构维度比如性能，手机APP聚焦在内存占用、电池的优化，而企业应用聚焦在数据的处理、应用部署的结构等。
但是，软件本身也有其共同的本质，比如性能、稳定、正确、有较大的自定义功能的便捷性。这些从架构维度思考，又有统一的思考方法和方式。
因此，软件架构具有独特性、同时也具有共通性。
软件产品的领域
就像创造一篇诗词或者写一篇议论文一样，一个软件架构的好坏首先取决于作者是否深刻理解了命题的主旨一样。比如写中秋诗词，主旨是思念亲人、思念故乡还是启发哲思，就能完全得到三组不同的词句“”“”“”，而写作手法却有相似借鉴之处。因此，理解主旨，也就是问题域，是真正区别好架构和劣质架构的根本标准。由此看来，劣质架构本身的技术特征或许并不坏，只是不适合它所要解决的问题。这是架构师是否成为架构师需要理解的第一奥义。
橘生淮南则为橘、生于淮北则为枳，在一个没有生命力的领域产生优良的架构几乎是领概率事件。
领域还包含另一层更重要的意义，就是上下文。跟你问题域相关的那些客观问题或者影响因素，也是架构需要密切关注的。因为软件本身也不是孤立存在的程序实体。一款有现实使用价值的软件产品必须和其他软件协同工作。
软件架构的落地实现问题
架构团队的贵族专制制度，包括架构团队的团结程度、影响力与威信
架构团队所在的软件研发队伍素质
架构团队本身的闭环能力
软件架构师应该知道如何更好的选择和应用技术
软件架构尽管有很强的主观成分。但是软件毕竟还是要一行行代码去实现。采用什么样的框架、中间件服务，运行时平台的规格等等，都是动手写代码的基础。选择什么样的关键技术，也是对架构师水平的考量。因此，软件架构师需要对关键技术有较强的把握能力才能将主观的“架构”变成实实在在的软件，使最终软件支撑架构设想，呈现出架构期望达成的目标。
软件架构的演进发展问题
常常有观点说，架构是演进出来的。这种观点本身揭示了软件架构的一个特征是，软件架构必须有生命力，就这一点上来说，是正确的。但是，仔细思考，演进的原点在哪里？原点从哪里来？这个观点的深层次矛盾似乎不如其字面这么直观。其原点本质上还是“设计”出来的，或者说是一种选择。比如软件采用容器还是虚拟机，采用ｊａｖａ还是Ｇｏ，这些都是一种架构原点的选择。而选择从哪里开始，往往对架构的功力有很广很深的考量和要求。
架构师的个人素质
并非每个人都适合做架构师，也不是你技术玩的溜就适合做架构师，架构师作为一个特定的行业职责，其倾向于具有以下素质的人。
产品精神，交付类的项目产生不了架构师。
产品精神的直观表现就是产品视角。当一个软件架构师在解决问题时，看到的是解决问题需要什么能力、特性，以及解决这个问题的能力特性需要有什么样的表现。而不是直觉式的思考技术实现方面。这时就具备了产品视角。否则只是技术视角，关注的还是实现，不是解决问题的能力构建。
商业理解力
客户理解力
洞察与分析能力
对技术的热爱
具有逻辑思维
信念与理想主义，也被说成是情怀。
具有较强的目标感。
怎么样能产生成功的软件架构？
首先要明白问题域，就是对待解决的问题要有一个清晰的判断和认识。进而想办法去解决它，这个时候才会涉及到架构选择的各个方面。