在组织架构框架内。
这里的组织是指组件、类、方法、包、服务等，这里的结构是指它们的内聚是否合理，它们之间的通信是否顺畅。
无论是宏观的服务与系统之间，还是微观的类、方法与技术之间，组织结构的设计都是我们关注的重点。
提示：“框架组织结构”中的“框架”一词在这里是介词。
这时候我们就清楚软件架构在构建什么了。
想一想，现实世界中的很多小需求、大需求、小项目、大项目往往并不是按照开发者的信念和愿望来发展的。 相反，它们层层嵌套，最终变得一团糟。 事物。
因此，为了防止出现杂乱的结果，我们需要进行软件架构，即对这些组织以及它们之间的关系进行梳理。
人们经常将软件架构与化学架构进行比较。
这并没有什么错，但也是错误的。
对于一座数学大楼，我们不管它的基础是石头还是水泥，不管它的形状是大胸罩还是鸟巢，不管它的风格是宏伟还是精致，我们一眼就能看出来。
不是吗？ 你看，这栋楼是不是像一个大胸罩？
然而，一个软件系统，你看一看，问你，它是什么样子，是“石头还是砖”做的。
你无法回答。
因此，我说，与建筑的类比也是错误的。
更无与伦比的是，长城千百年来屹立在那里，从未改变过它的本质面貌。 问问你的系统和你的应用，一年之内、半年之内、两个月之内，“添砖加瓦”的次数和变化的频率。
是的，你时不时就会遇到需求软件架构师应该知道的97件事，然后你把需求实现到你的软件系统中。 之后，你的软件系统将会发生变化，添加新的功能，并提高更高的性能。 事实上，相反也是有可能的。
是的，在变化中，软件和架构的区别就是变化，软件仍然会变化，架构不会。
不仅是变化，期间还有各种约束，比如这个类的设计是否单一，内聚性是否足够强，远程调用超时后怎么办等等。
还有硬件限制。
CPU速度和网络带宽往往在很大程度上决定系统性能，显存和存储空间的大小也会极大地影响代码设计的野心。
疯了，我不想接受这么多的要求软件架构师应该知道的97件事，但是，下次你就会被要求狠狠地打一巴掌。
莎士比亚，我告诉你：“女士，这就是感情的恶毒。人的愿望是无限的，但实际的行动却处处有限。人的欲望是无穷无尽的，但行动却要符合现实的有限性。”
需求是原罪，也是动力。 它是软件、系统和企业发展的动力。
软件架构师真的比架构师更了解架构吗？ 是的，一定是的。 如果你是一名建筑师，请相信这一点。
一个好的架构不仅要满足软件用户、开发者、所有者在特定时刻的需求，还要持续满足他们后续一段时间内的需求。
提示：为什么，这是一段时间。 因为软件是有生命周期的。
我只想设计一个框架，即使需求变、变、变，我也能适应。
除了你思考之外，思考一切。
“他强，他强，清风吹山，他强横，月照江水，他无情，他邪恶，我精神饱满。”
于是，人们总结了很多设计原则、设计模式、设计理念，以最大限度地适应和兼容现实世界的这些变化。
TIP：没办法，人类的整个经济活动都存在于现实世界中，企业软件也不例外。
最终，软件架构设计的大师们发现了软件架构设计的最终技术目标：正交分解。
TIP：软件架构设计的最终商业目标：最大化程序员的生产力，最小化系统的总运营成本。
对系统的例行更改是不可避免的。 正如我们之前所说，有需求是一件好事。 程序员有“生意”要做，企业也有生意要做。
但这种例行的改变不应该是昂贵的，也不应该需要无法决定的小的设计调整，也不应该需要一个单独的项目来完成。
我们应该把软件架构的目标对象：组织（类、方法……你已经学过）划分为外围模块和核心模块，或者外围系统和核心系统，虽然系统也可以看成是一个模块，宏模块，只是跨进程模块。
确保我们的核心模块是只读的，所有分散的需求，无论大小，都应该扔到外围模块中去实现。 如果你想用砖块和砂浆建造，就去任何你想去的地方。
这就是软件架构设计的正交分解。
提示：核心模块是只读的。 尽量保证大多数情况下，其内部代码不需要被触及。 如果你坚持提供数字评论，在 90% 的情况下，它将是只读的。
您一定听说过并理解 SOLID 原则。 这五个原则之间是有联系的。 最直接的联系是，单一责任为始，开闭原则为终。
没错，你很聪明，你已经知道如何设计一个正交分解的软件组织结构：朝向交换机。
至此，我已经熟悉了软件的组织结构，也掌握了正交分解。 我也想“进步”。 如何预测某个软件系统未来的变更需求，以便提前规划？
《金钢经》告诉你：“佛说世间非世间，故名世间”。 哲学还告诉你，所谓软件架构，就是你希望在项目一开始就做对，但你可能做不到。 正确决策的集合。
我祝愿我们的建筑师“做得好”。
