Javascript 架构模式是对开放/封闭原则的极端违反

我正在开发一个web应用程序，它将在给定一组有界参数的情况下自动生成引导站点。我需要关于架构决策的帮助，因为随着时间的推移，我已经做出了非常幼稚的设计决策，我不想在这个项目中重复这个错误。对于我的PoC，我采用MVC方法进行设计，顶层架构（见上文）包含以下内容：

• CanvasComponent——这是应用程序的入口点，用户可以在其中生成自己的网站并下载

• CanvasService-此服务协调网站的创建，并依赖于一组服务（NavbarService、HeroService、FooterService）

• DomService-此服务负责在高级SAN样式中创建DOM元素

• ComponentService——这些服务组（NavbarService、HeroService、FooterService）负责在较低级别创建DOM元素

• FontService-此服务是一个Google字体库

以上是我相当快地组合起来的东西，所以我知道它并不完美。在我走向产品化的过程中，我还对项目的方向、it的可扩展性提出了一些问题。这些是我的问题：

我给某人看了，他们说他们看不懂。。。听起来像我的CanvasService，DomService和组件服务创建原始HTML，所有这些都是描述DOM元素的模型。这似乎是非常错误的设计。我们开发服务的方式不可扩展，也不可管理。如果没有其他原因，这是对开放/封闭原则的极端违反。它们最终将成为巨大的“工厂”，不能完全覆盖DOM元素的所有功能这是我主要关心的问题。如何从架构的角度解决此问题？

鉴于该项目的性质，我正在广泛地处理原始html。我使用多种方法来动态生成所需的HTML。我想问的是，上述做法是否可取。在架构上，创建和管理HTML块最干净的方法是什么？我应该使用原始字符串还是创建更定制的字符串

存储每个组件（导航栏、英雄、页脚）的样式组合，然后随机应用它们的最佳方法是什么？据我所知，风格可以分为两类——模板和主题。一个模板可以有许多主题，一个主题可以与多个主题关联。一个很好的例子是网站上的“亮/暗”颜色模式。目前在NavbarService中，我将一系列可能的宽度和高度存储在一个数组中

除了违反开闭原则（未知的未知因素）之外，我当前的架构方法还会出现什么问题吗？在过去，每当我开始这样的项目时，它们都很快变得不可持续。我失去了兴趣，因为那时我正在与代码库搏斗。我希望这个过程继续令人愉快，在整个项目过程中保持我的代码干净、易于管理，并应用最佳原则

---

这里有一个示例演示：（每次重新加载页面时，都会出现一个新的导航栏）。

这是一个有趣的问题。我也不太理解这个图表，但是你的描述更有意义

让我们假设您生成的HTML/CSS/JS组件是合理编写的，并生成合理的格式和合理的输出。在这一点上，您实际上不需要存储关于它的元数据，因为任何东西都是不需要的。您需要的是能够构造小的模块化代码块，这些代码块可以在编辑或添加输入参数后重新编译

为了支持这一点，我强烈建议将代码（HTML）的输出分离为带有版本戳的解决方案库，而生成的代码应该是来自用户或数据输入的标记数据的集合

要创建一个简单的类比，请想象公式（8+1+1=10）

在本例中，输出（10）是唯一需要发布/呈现/存储的内容。但是，您需要保持起始数据（8+1+1）的独立性-主要是因为如果其中一个值发生变化（比如现在是8+2+1），您现在可以使用新版本重新生成第二个版本的输出，并获得新的答案（11）

因此，我更关注于存储构建块/所见即所得/标记组件，而不是担心输出元素的字符串/文本格式。从架构的角度来看，如果您有任何交互/修改此代码的持续需求，那么您需要关注易用性和可重用性

还请记住，除非您正在创建skynet，否则您并不是在编写“编写代码的代码”。您正在编写帮助人类编写代码的代码。始终假设需要来自外部来源的干预和修改-重点是获取（算法+输入=输出）的模块形式，并存储流程和输入。如果你做对了，你可以在任何时候出于任何原因重新生成输出