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