通过学习，首先了解了什么是架构，架构是：如果把一个问题看作一个整体，把这个整体分成不同的部分，把每一部分分给不同的角色，这些角色之间可以相互沟通，并且具有一定的联系机制，使得这些部分能够根据这个机制的结合为一个整体，来完成这个整体所需要的目标活动。架构是如何产生的，因为一个整体如果都由一个角色完成，那么这个角色就会负载过重，一个角色的能力、时间和空间都是有限的，为了更高的要求和利益的最大化，不得已就会出现分工，这些分工之间具有相互沟通的机制，这些部分可以通过这个机制结合成一个整体，完成整体目标活动。因此架构的产生是一个必然结果。用我的家庭生活为例，一个家庭的生活也是架构，这个架构的触发是因为人要衣食住行，家庭成员包括爸爸 妈妈 我和弟弟。家庭中的业务包括买菜、做饭、洗碗、扫地拖地、擦桌子、洗衣服等。家中的业务分配为：爸爸执行买菜、洗碗的业务，现在在疫情期间，有买菜专门送到小区门外的商家，妈妈说要做什么饭，爸爸买菜到门口拿，评价的标准主要看菜是否新鲜和与妈妈的期望是否符合；妈妈执行做饭和洗衣服的业务，用天然气做饭，用洗衣机洗衣服，部分衣服需要手洗，通过品尝和穿衣服来评价业务效果，评价标准是饭菜可口，衣服干净；我执行扫地拖地的业务，每天早上执行，用过是否干净来评价业务效果，评价的标准是地上没有头发；弟弟执行擦桌子的业务，用一块干净的布擦电视柜、茶几、鞋柜等，通过擦得是否干净来评价业务效果，评价得标准是不能有灰尘。
然后我们还需要明白什么是架构师，如果一个人在工作中，只是致力于完成自己的工作，以做好自己的工作为主要目标，那么最多只能成为一个工匠，无法成为一个架构师。如果我们把完成别人工作和自己的利益结合起来，更好的去发现问题了。只有做到这一点，才能在自己所服务的领域建立起自信，成为一个合格的架构师。架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。架构师还必须要明白，所给出的解决方案 -- 架构的分拆、合并方案，只有让问题的主体的权责对等，才能够真正的解决别人的问题。架构师必须明白软件本身是怎么回事，解决什么问题，还要解决软件所服务的对象的领域本身是怎么回事，解决什么问题。
在架构中有一个问题是非常重要的，就是架构解决谁的问题，如果我们在遇到问题时过于关注解决问题，急于完成自己的工作，而忽略了导致问题的真正的原因，凭自己的直觉下判断，这样一定会导致错误的出现，我们在遇到问题时，通常被告知要处理一个问题，但是交过来的实际上是一个解决方案，不是问题本身，而我们也急于完成工作，直接通过直觉就有了一个解决方案，马上考虑解决方案如何落地，或者有几种解决方案，选哪个合适，这样的方式是不可取的，一名架构师，要首先找到是要解决谁的问题，只有明白了是要解决谁的问题，接下来的讨论才有意义。发现问题比解决问题更加重要，而在架构师的工作中，通常要解决的也是别人的问题，找到问题的主体非常重要，架构师需要识别：用户究竟是二传手，还是问题的真正主体。
接下来架构师需要做的是架构切分，因为每个人的精力、时间都是有限的，一个人不可能完成所有的工作，并且为了利益的最大化，分工非常重要，也是必然选择。架构的切分需要遵循一定的原则：必须在连续时间内发生的一个活动；分工之后每部分的负责人，对这个部分的权利和义务必须是对等的，并且每部分不能超出人的负载；无论工作如何切分，这个系统的整体目标任务是不能改变的。
软件架构包括了，代码架构以及运行代码所需要的硬件部署架构，架构师要结合每个部署单元所承担的责任，进行拆分，保证每一部分可以独立变化，不产生连锁反应，拆分成几个职责，系统要专注于使用者的需求，要专注于实现业务的核心模型，要专注于数据的保存，并和存储设备一一对应。架构师也要又一定的业务逻辑，如果没有一定的逻辑，最终会导致损失用户的利益，并且肯定会导致返工，损坏自己的利益，Glue Code 里面要严格的顺序调用，Repository 里面如果不是严格的顺序调用，包括存储访问的代码里面（比如 SQL）。
合理处理业务、技术还有架构的关系也尤为重要，业务的目标是为了技术，技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提；如果技术的效率不高就会影响业务的效率；在解决同一个业务问题的前提下，更高效，更低成本的技术，会淘汰低效，高成本的技术；架构师应该承担起解决业务问题，业务就相当于人的大脑，而技术相当于人的四肢，架构师应该更注重的是解决业务中的问题，因为只有大脑运作起来才能带动四肢，架构师应该致力于为业务在计算机中跑起来而努力。只有把业务和技术很好的结合起来，才能更好地完成业务的目标。