摘抄出处：软件架构到底是要解决什么问题？

一、虚拟化业务需要完成这些事情：

  1. 学习业务知识，认识业务所涉及的stakeholders的核心利益述求，以及业务是如何分拆满足这些利益述求，并通过怎样的组织架构完成整个组织的核心利益的，以及业务运作的流程，涉及到哪些概念，有哪些权利和责任等。
  2. 通过对业务知识的学习，针对这些概念所对应的权利和责任以及组织架构，对业务进行建模，把并把建模的结果用编程语言实现。这是业务的模型，通常是现实生活中利益斗争的结果，是非常稳定的。
  3. 学习业务所参与的stakeholder是如何和业务打交道，并完成每个人的权利和义务的，并通过编程语言，结合业务模型实现这些打交道的沟通通道。这部分是变化最频繁的，属于组合关系。明白了这一点，对后续的实现非常有帮助。
  4. 如何把业务运行的结果，持久化，并通过合适的手段把持久化后的数据，在合适的时间合适的地点加载出来。这部分和基础设施有关，变化可能也会比较频繁。

二、代码如何运营，需要完成这些事情：

  1. 需要多少硬件设备来满足访问的需求？
  2. 代码要分成多少个组件部署到哪些硬件设备上？
  3. 这些代码如何通过硬件设备互相连接在一起？
  4. 当业务流量增大到超过一台机器的容量时，软件能否支持通过部署到新增机器上的方式，扩大对业务的支撑？
  5. 当某台或某些硬件设备失效时，软件是否仍然能够不影响用户的访问。
  6. 软件运行产生的数据，能否支持提取出来并加以分析，为下一轮的业务决策提供依据。

三、如果分成不同的角色来完成这些事情，就需要一个组织架构来组织代码的编写和运营，需要做哪些事情：

  1. 完成一和二所列的这些事情，需要哪些角色参与？
  2. 这些事情基本都需要顺序的发生，如何保证信息在不同角色的传递过程中不会有损失？
  3. 或者说即使有损失，也能快速纠正？
  4. 这些角色之间是如何协调，才能共同完成虚拟化业务的需求？

其他摘录

摘录文章理清技术、业务和架构的关系

在软件设计开发的过程中经常会看到，很多所谓的架构讨论实际上只是在讨论某种技术。在很多人的概念里面，架构和技术实际上是等同的。学会了几种技术，就认为自己是架构师了，甚至是学习的技术越多，就觉得自己的水平越高。这样实际上是对自己很不负责任的。要知道任何技术都是为了解决某种问题而存在的，学会了技术，并不代表自己能够解决问题，这一点非常的重要。学会的技术的多少，所带来的差别只是自己解决问题的手段多了罢了。但是手段多了就一定是好事吗？ 很多时候，学习的技术越多，越不知道采用哪种技术好，所谓“乱花渐欲迷人眼”。

还有另一种很普遍的观点：技术人普遍看不起业务，认为技术更高端，而业务太低端，并且业务往往喜欢给技术挖坑。业务则觉得技术眼光高，但是实际解决不了问题，总是理解有偏差，但是又无可奈何，因为自己不会。

一般是先有技术，才会有架构。