软件架构，到底在架构什么。
在架构组织结构。
这里的组织，是指，组件、类、方法、包、服务等等，这里的结构是指它们的内聚性是否合理，它们之间的通信是否顺畅。
无论从宏观的服务与服务、系统与系统之间，还是微观的类与类、方法与方法之间，对组织结构的设计都是我们的重点。
TIP：“在架构组织结构”中的架构在这里是一个动词。
这时，我们就很清楚软件架构到底在架构什么了。
想想也是，现实世界中的许多小需求、大需求、小项目、大项目，往往并不会按照研发人员的信念和愿望生长，相反，层层嵌套，最终绕成一团乱麻，倒是常有的事。
所以，为了不让乱麻的结果出现，我们就要进行软件架构，也就是去梳理那些组织，和它们之间的关系。
人们常常将软件架构和物理建筑做对比。
这没有错，但也错了。
一幢物理的建筑，我们不管它的地基是石头还是水泥，形状是大裤衩，还是什么巢，风格是气势恢宏，还是小巧玲珑，看一眼，就一目了然。
不是么，看，这个楼不就是像个大裤衩么。
可是，一个软件系统，你看一眼，问你，长什么样，用“石头还是砖头”做成的。
你答不上来。
所以，和建筑类比，我说，也错了。
更不可比的是，长城有几千年一直魏然矗立在那里，未曾变过本质模样，问问你的系统，你的应用，一年之内、半年之内、两个月之内，你“添砖加瓦”的次数，改动的频率。
是吧，你会经常被需求击中，然后你再把需求实现到你的软件系统中，然后你的软件系统就会发生变化，长了新的功能，提升了更高的性能，当然，也可能，相反。
对，在变化，软件和建筑的区别，是变化，软件一直变化，建筑不会。
不仅仅变化，期间还要受到各种约束，这个类设计的是否单一，内聚性是否足够强，远程调用超时之后怎么办，等等。
还有硬件上的限制。
CPU速度和网络带宽往往在很大程度上决定了系统的性能，而内存和存储空间的大小也会大幅影响代码设计的野心。
疯狂，我就不想接那么多的需求，但是，下一次你又会被需求狠狠的抽一个耳光。
莎士比亚，告诉你，“女士，这就是爱情的穷凶极恶之处，人的意愿是无穷的，而实际行动却处处受限。人的欲望是无止境的，行为却不得不遵从现实的限制”。
需求，是原罪，也是动力，是让软件，让系统，让企业发展的动力。
是不是，软件架构师比建筑师更懂架构呢，是的，一定是的，如果你是一名架构师，也请你坚信这点。
一个好的架构，不仅要在某一特定时刻满足软件用户、开发者和所有者的需求，更要在一段时间内持续满足他们的后续需求。
TIP：为什么，要说是一段时间内呢。因为，软件都是生命周期的。
我就想设计一个，任凭需求变、变、变，而我全都适应的架构。
不仅你想，是都想。
“他强由他强，清风拂山岗，他横由他横，明月照大江，他自狠来他自恶，我自一口真气足。”
于是，人们总结出来来好多设计原则、设计模式、设计理念，最大化程度去适应，去兼容这种现实世界发生的变化。
TIP：没有办法，人类的整个经济活动都是存在于现实世界中的，企业软件也不例外。
最终，软件架构设计的前辈们，发现了软件架构设计的技术终极目标：正交分解。
TIP：软件架构设计的业务终极目标：最大化程序员的生产力，最小化系统的总运营成本。
一个系统的常规变更是不可避免的，这点我们说过，有需求是好事，程序员有“生意”做，企业也有生意做。
但这样的常规变更不应该是成本高昂的，也不应该需要难以决策的大型设计调整，更不应该需要单独的立项来完成。
我们应该将软件架构的目标对象：组织（类、方法、...上面你已经了解过），分成周边模块，和核心模块，或者是周边系统和核心系统，其实系统也可以看成是模块，宏观的模块，跨进程的模块而已。
保障我们的核心模块是只读的，大大小小，零零散散的需求都应该扔到周边模块中去实现，想舔砖加瓦，到那里去。
这就是软件架构设计的正交分解。
TIP：核心模块只读，尽可能保障大部分情况下，不用动它内部的代码，如果硬要给个数字考量的化，90%情况下，只读。
你一定听说过，也了解SOLID原则，这五个原则之间是有联系的，其中最直接的一个联系就是，单一职责是开始，开闭原则是结尾。
没错，聪明的你，已经知道该该如何设计出正交分解的软件组织结构了：朝着开闭去。
到了这里，我熟知了软件的组织结构，也掌握了正交分解，还想“得寸进尺”，我怎么能够预知某个软件系统未来的变更需求，以便提前做准备呢？
金刚经，告诉你，“佛说世界，即非世界，故名世界”，哲学还告诉你，所谓软件架构，就是你希望在项目一开始就能做对，但是却不一定能够做得对的决策的集合。
祝我们的架构师们，“好自为之”。
