软件架构师需要发现问题并且解决问题。架构师必须具备一定程度的自信，要去真正的发现问题的主体，识别真正的问题，并把这个行为变成为自己面对问题的第一反应。
Service就专注于user的需求，并组合Glue Code提供的服务完成需求。
Glue Code专注于组合business的调用，管理Business里面对象的生命周期，并且通过Repository保存或加载Business的状态
Business专注于实现业务的核心模型。
Repository专注于数据的保存，并和存储设备一一对应。
业务逻辑：软件代码中的逻辑，在软件代码中，除了缩进的代码目的是cache exception的，都不算逻辑以外都是逻辑。
Service、Glue Code、Repository里面的代码是严格的顺序调用，那么这些代码只要做连通性测试即可，不需要单元测试。
技术、业务和架构之间的关系：
技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术。先有技术，才会有架构。技术是从直接解决问题的初始主要技术中分拆出来形成的，并通过树状结构和主要技术组合在一起。
技术与技术之间之间，更高效的低成本的技术会淘汰低效高成本的技术，新的技术是在原来技术上进行改进的。新技术和原有的技术是一个整体，新技术和原有技术能够一起工作。
先有技术才会有架构，技术是从直接解决问题的初始主要技术中分拆出来的，解决了主要问题就会分拆出更细粒度的技术。不同的技术，通过树状结构，组合在一起，形成了一个完整的架构解决方案，共同完成业务的目标。这就是技术，业务和架构之间的关系。
技术人员和业务人员的关系
技术人员很多时候关心的技术，和业务的主要目标往往不是直接对应的，业务也是负责某一部分的业务，也不是和业务的主要目标直接对应的，都是树的分支节点，因此就会产生冲突。
软件架构师需要承担解决问题的角色，需要将业务和计算机很好的结合起来，能更好的完成业务的目标，能够更高效的开展工作并且节约成本。
我们需要有意识的组织和识别不同的技术，来实现业务目标，进行架构拆分，分拆成更细粒度的问题，分解成不同的人来进行解决，就形成了业务架构和组织架构，需要我们将技术技术所解决的问题和分拆出来的要解决问题完美匹配，越复杂的技术，成本越高，如果自己实现一个解决当前问题的方案，成本会更低。当技术所提供的能力和我们所要解决的问题部分匹配时，还要看成本。我们需要根据长期的成本和收益来识别采用什么技术的能力。