企业环境中应用程序的开发生命周期通常遵循一个共同的主题。 应用程序一开始就要有明确的目标，随着时间的流逝，引入的要求会导致原始概念范围的增加。 这些增加的内容可能与原始概念完全同步，或者可能只是没有更好的归属感而已。随着应用程序的成熟到使用寿命终止，它现在已经远远超出了其最初的预期目的，并且在迫切需要进行重构-将整块野兽分解为更小，更简洁的组件。
这个故事是席卷企业界的微服务架构转型的命脉。 能够模块化组件并通过有针对性的扩展来提高产品上市率的想法，但代价是系统的复杂性增加。 我一直感兴趣的一个问题是“如何？”。 这种转变如何发生？ 您如何形象化地向他人解释您的概念？ 我想提供一个观点，我认为它非常直观地模仿了这种企业发展转型。
我真的只是从自然界复制一个模式，并在不同的背景下使用它，在这种情况下，就是典型恒星的生命周期。 恒星燃烧其燃料寿命长，最终随着燃料的消耗而变大。 当没有燃料剩余时，这颗恒星现在是一个巨大的红色巨人，它将爆炸并将太阳系中剩余的一切消灭为天尘。 多年过去了，尘埃凝聚成更大的物体，最终使我们有了小行星，卫星，行星和另一个婴儿恒星。 要详细说明这与应用程序生命周期之间的关系，一个应用程序就像星星一样，随着时间的推移会变大，直到变得太大并分离成基础块再重新构建。
将恒星超新星余波中的每个尘埃颗粒视为一个逻辑单元。 它可能是业务逻辑，数据库查询或连接，模型等。几乎所有内容。 这些尘埃在整个系统中均匀地随机分布，没有尘埃粒子对另一种尘埃产生偏见（至今）。
为了使尘埃颗粒开始相互粘附，我们应该考虑用户流量以及他们需要哪些尘埃颗粒。 用户在粒子海中遍历的每个流都留下一条连接它们并将它们拉近的轨迹。 每个流彼此建立，最终留下最有用的热点热图。 我建议这些热点是您的新上下文边界！ 将这些新边界视为彼此的轨道体。 您可能有一颗行星恒星，而那些行星可能有卫星。 流氓组件可能充当两个主要系统之间的适配器； 我建议将其视为穿越多个太阳系的彗星。
我以前从未见过这个概念或术语，因此，如果有的话，我想创造它，即Solar Architecture / Design。
在确定这些边界之后，这种观点为您提供了实现方面的很大灵活性。 选择使用模块化的整体组件或选择云中的微服务没有任何限制，尽管其真正的优势在于系统的结构图。 我避开将复杂系统描述为简单层的想法，或者让体系结构蔓延到网络图表中的连接线混乱之中，这需要更多时间来记住所涉及的内容，因此您不会破坏任何事物而不是创造价值。
当您开始将复杂系统视为轨道物体时，（至少对我而言）了解系统中的新要求应该变得更加容易（至少对我而言）。 更容易理解如何将新需求吸收到该模型中。 它们可能会毫不费力地掉入太阳中，或者可能是一个巨大的恐龙灭绝事件，对于一个行星而言，应该引起对特定环境设计的重新评估。 我也喜欢数据的组织，因为我喜欢遵循建议，即从真相来源到边缘要做到单一程度的分离。
不可避免的是，无论您选择哪种方法来重构系统，都无法避免随着语言和技术的变化而在未来进行另一次改进。 我认为Solar Architecture的一个可争议的缺点是，是否同时将这种技术应用于整个组织，尽管我认为这也很合适。 太多的材料会使这种类型的模型崩溃（当然，我本来打算在这个概念的某个地方使用黑洞这个比喻！），而是应该考虑将该公司视为具有多个太阳系绕行的银河系的核心。
总而言之，我认为将物理世界联系在一起的定律也适用于我们技术系统的无形组织，我期待着进一步探索这一概念。