一、缘起
作为程序员，很容易天天被业务追逐着，抽不开时间修炼。有一天突然停了一下，忽地就会有一种怅然的感觉，过去的那些日子我学到了什么/span>
有人很认真地说自己有10年经验，有人笑说你不过是一年经验用了10年而已。
二、师傅领进门
做人，做事，做架构师–架构师能力模型解析这篇文章，已经把架构师的能力总结好了，简单就是两个词，做人、做事。在上文中，作者提出了作为架构师做事需要做好的事情如下图，特别有道理，特别值得再细细品味一下
什么样的架构师是一个会做事的架构师能做设计、做决策、关键时刻还要自己能光着膀子上。也就是下得了厨房，上得了厅堂。
架构师是一个有全局观的设计师，有全局观的程序员。大家都在低着头走路的时候，他偶尔看了看天上的天象。
三、读万卷书、行万里路
架构模式的种类 一文把模式按层次分成三种：架构模式(Architectural Pattern)、设计模式(Design Pattern)、成例(Idiom)。成例有时称为代码模式(Coding Pattern)。这三者之间的区别在于三种不同的模式存在于它们各自的抽象层次和具体层次上。架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。
今天只想探索最酷炫的架构模式。 架构的美只有架构师的眼中才能看得到。大家都看着的只是一堆砖泥瓦的时候，只有架构师最清楚这个地方以后会长出来一个多么漂亮的高楼。
main函数入口： 所有的系统，都有一个入口。大家都是从最简单的main函数开始，只是为何有的就只是print一个helloword，有的在做高密度的计算把CPU耗成100%，有的起了一个健壮的服务，有的建起了一个漂亮的花花世界。 就像还是种子的时候看起来，种子样子都是差不多的，最后长成的样子会是千差万别。 一定要看好main的入口，一个看不起眼的地方，也是万物萌芽的地方。
ApplicationContext： 好多系统都有一个ApplicationContext，小白的话可能没有注意到它。更多的人是瞥了一眼ApplicationContext，当作没存在直接上去就搞业务。这样的问题就是导致建的房子就像是一栋没有地基的房子，错乱搭建起来，杂乱无章。 很多系统ApplicationContext做了很多奇奇怪怪的初始化，然后这个系统的地基打好了。 然后很多人可以在上面工作了，很多很多人。 系统的地基就是系统的核心框架，就是在ApplicationContext里面加载完毕的。
基础服务和common组件： 系统的框架已经在ApplicationContext中搭好了。 框架上首先运行着系统的心脏， 也就是系统的基础服务和common组件，是工业时代的水和电。 很多系统都有一个ServiceManager.getService(xxx)，或者是xxxFactory.createXXX()
业务单元： 系统框架已经搭好，基础服务和公共组件库也建好了以后，业务单元就可以百花齐放了。 很多人 可以同时用系统共享的水和电一起开工建房子了，然后直接一拼，联排别墅已经建好，这也太神速了吧。 所以很多人以为自己建房子挺快的，以为建一个房子很容易，其实他更像是在装修一个毛坯房。
一个架构模式描述软件系统里的基本的结构组织或纲要。 架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。
-
类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大 房子各式各样的设计都有，但是里面的组件是可以共享的 外面对接的是Controller，从数据服务取出数据拼成Model，画到View上去 应用层逻辑比较复杂，交互较多。 MVC以来的主要设计原则：单一职责、迪米特法则又叫最少知道原则、组合模式、接口隔离
为什么要插件框架/span> 每个人都可以把自己的房间打扮成自己想要的模样， 水和电都是共享的，但是房间确实不一样的，那就是各式各样的插件了
悟的时候，时光要慢了下来，偶尔的灵光一现自己也能感觉到。 别人看我是一个搬砖工，我觉得自己在建一座宏伟的教堂。
来源：黄舒颖 咸丫蛋
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！