软件架构

    架构所存在就是为了将整体切分为个体所完成的任务，在由人来指挥进行到整体的转变，而架构所能解决的也都是关于人的问题，也只有人的相关复杂问题才需要架构的设计。而切分又是架构中重要的一环，当一个人离开了社会的这种切分，而想要独自一人完成整体的，他毫无疑问是会被社会所淘汰的。切分本质上还是时间上的负载。这个负载是针对人的方面，因为涉及到切分，就会产生对切分部分的如何切，怎样分。以及切分中责任和义务的具体指代。以及透明化的切分等等。正是因为整体之大，所以才会产生切分，其中的切分所合起来也就是重回这个整体。

      在简单的了解完架构与切分之后，而提到架构，就不得不提出，软件。从古至今的软件发展，其中所依据的，最主要的就是，成本是我们为什么采用软件的主要动力。而软件从一开始一人小团队，渐渐提升到多人团队，软件架构这个词也渐渐的浮出水面。因为本身软件工程师的压力也在一步步增加。对整体的把控也是很有必要的。各司其职也能直接提升参与人的利益。就和所有的架构一样，软件架构师也就此进入公众的视野。

       架构师必须是一个组织的领导人， 他必须有权力来调动整个团队，以及能够有能力从整体切分到个体进行分析。但是成为一个软件架构师可不是那么容易的。首先，只致力于自己的工作，已把自己的工作完成当作目标，而不去思考整个团队的项目联系的肯定是不适合软件架构师所需要做的就是克服对自己工作的恐惧，把完成别人的工作，完成团队的工作作为自己的最大利益。而此时你的思想也需要进行一个更高层面的转变。假如这个项目没有解决。究竟谁会有利益的损失？如果解决了，谁会有收益，谁的收益最大。让事情的权责对应起来，就是一个顶级架构师所要想的和解决的。而正因为他有这样的权力，他就要着承担整体架构和设计的义务，他是一个团队的核心，也必须更多的勇气来承担整个项目的所有。切勿为了图方便而让这个职业在公司中形同虚设。这样反而会背道而驰。

       那软件架构师也离不开代码层面的设计和运用。其中就有着代码架构，而有时候大家说的代码推翻重写，毫无疑问是在前期架构方面没有充分准备，导致代码像一坨屎山一样。其实代码就是对现实生活的模拟，虚拟化。所以我们的代码应该分为，表达业务逻辑的代码和对用户提供访问并保存业务逻辑运行结果的代码。

      其中分了这几种责任，1.Service 就专注于 user 的需求，并组合 Glue Code 提供的服务完成需求；2.Glue Code 专注于组合 business 的调用，管理 Business 里面对象的生命周期，并且通过 Repository 保存或加载 Business 的状态；3.Business 专注于实现业务的核心模型；4.Repository 专注于数据的保存，并和存储设备一一对应。而逻辑只允许存在于 Business 中，Service，Glue Code，Repository 都不允许存在业务逻辑。

       那首先我们要明白什么是业务逻辑，这个定义的前提是指软件代码中的逻辑，不是现实生活中的逻辑。在软件代码中，不需缩进和计算的顺序调用，包括缩进的代码目的是 catch exception 的，都不算逻辑，除此以外都是逻辑。其中 Service，Glue Code，Repository 里面的代码都是严格的顺序调用，这些代码很难进行单元测试。而Business不访问上下文，不访问任何设备，进行单元测试是很简单的，正因为其他地方没有业务逻辑，所以出问题之后基本就是 Model 的问题。这样的话也会让测试更加的方便。也正由于 Service，Glue Code，Repository代码简单了，我们才能有更多时间投入业务的研究，所以当我们作为一个软件架构师真正的完成代码工作的时候，让该出现逻辑的地方出现逻辑，让不该出现的地方不出现。

        而业务，技术，架构之间的关系也是需要处理的，技术是为了解决业务的问题而产生的，技术之间会相互迭代，更新更快的技术会淘汰老技术，从而在解决同一个业务问题中，选择更新更快的技术是毫无疑问的。而业务的不断发展也会促成各种新兴技术的产生。而有了技术，就有了架构，架构将各技术层面切分从而更加容易的完成当前工作。就像工作中，业务人员和技术人员总会因为各种各样的问题发生冲突，而这个时候就需要架构师承担解决业务问题这个角色，因为架构师能够综合考虑各方面的相关问题，联动调整业务，技术，架构之间的问题。