架构模式是对open/closed原则的极端违背
Architecture pattern is an extreme violation of the open/closed principle
我正在开发一个网络应用程序，它会在给定一组有限参数的情况下自动生成 Bootstrap 网站。我在架构决策方面需要帮助，因为随着时间的推移，我做出了非常幼稚的设计决策，我不想在这个项目中重蹈覆辙。对于我的 PoC，我采用了 MVC 方法进行设计，顶层架构（见上文）包含以下内容：
CanvasComponent - 这是应用程序的入口点，一个 UI 元素，用户可以在其中生成他们的网站并下载它；
CanvasService - 此服务协调网站的创建，并依赖于一组服务（NavbarService、HeroService、FooterService）；
DomService - 此服务负责在无样式的高层创建 DOM 元素；
ComponentService - 这些服务组（NavbarService、HeroService、FooterService）负责在较低级别创建 DOM 元素；
FontService - 此服务是 Google 字体存储库。
以上内容是我很快整理出来的，所以我知道它并不完美。在我走向生产化过程中，我还对项目的可扩展性方向有一些疑问。这些是我的问题：
我把它展示给别人看，他们说他们无法理解...因为听起来我的 CanvasService、DomService 和组件服务创建原始 HTML，所有这是描述 DOM 元素的模型。这似乎是非常错误的设计。我们开发服务的方式无法扩展或管理。如果不出意外，这是对open/closed原则的极端违反。它们最终将成为无法完全覆盖 DOM 元素所有功能的巨大“工厂”。 这是我最关心的问题。如何从架构的角度解决这个问题？
鉴于项目的性质，我正在大量处理原始 html。我混合使用多种方法来动态生成所需的 HTML。我想问一下以上是否可取。在架构上创建和管理 HTML 块的最简洁方法是什么？我应该使用原始字符串还是创建更定制的内容？
为每个组件（导航栏、英雄、页脚）存储各种样式然后随机应用它们的最佳方法是什么？据我了解，样式可以分为两类 - 模板和主题。一个模板可以有多个主题，一个主题可以关联多个主题。一个很好的例子是网站上的“light/dark”颜色模式。目前在 NavbarService 中，我将一系列可能的宽度和高度存储在一个数组中。
除了违反开闭原则（unknown unknown）之外，我当前的架构方法是否还会出现其他问题？过去，每当我开始这样的项目时，它们很快就会变得不可持续。我失去了兴趣，因为那时我正在与代码库搏斗。我希望这个过程继续愉快，并在整个项目过程中保持我的代码干净和可管理，并应用最佳原则。
此处提供示例演示：https://stackblitz.com/edit/angular-ivy-2pga8q（每次重新加载页面时，都会出现一个新的导航栏）。
这是一个有趣的问题。我也不太明白图表，但你的描述更有意义。
让我们暂时假设您生成的 HTML/CSS/JS 组件编写合理，并生成格式合理且合理的输出。在这一点上，您实际上并没有 'need' 来存储关于它的元数据，因为任何不需要的东西都会膨胀。您需要的是构建小型模块化代码块的能力，这些代码块可以在编辑或附加输入参数后再次重新编译。
为了支持这一点，我强烈建议将代码 (HTML) 的输出分离为带有版本标记的解决方案库 - 并且生成的代码应该是来自用户或数据输入。
创建一个简单的类比，想象一下公式 (8+1+1=10)。
在此示例中，输出 (10) 是您唯一需要 publish/present/store 的东西。但是，您需要保持起始数据 (8+1+1) 独立 - 主要是因为如果其中一个值发生变化（比如现在是 8+2+1），您现在可以使用新的输出重新生成第二个版本版本并获得新答案 (11)。
因此，与担心输出元素的 string/text 格式相比，我会更多地关注存储构建 blocks/wysiwyg/mark 组件。从架构的角度来看，如果您有任何持续需要 interact/modify 此代码，您需要关注易用性和可重用性。
还请记住，除非您正在创建天网，否则您就不是在编写 'code that writes code'。您正在编写代码来帮助人类编写代码。始终假设需要从外部来源进行干预和修改 - 专注于获取（算法 + 输入 = 输出）的模块化形式并存储过程和输入。如果你做对了，你可以随时出于任何原因重新生成输出。
我正在开发一个网络应用程序，它会在给定一组有限参数的情况下自动生成 Bootstrap 网站。我在架构决策方面需要帮助，因为随着时间的推移，我做出了非常幼稚的设计决策，我不想在这个项目中重蹈覆辙。对于我的 PoC，我采用了 MVC 方法进行设计，顶层架构（见上文）包含以下内容：
CanvasComponent - 这是应用程序的入口点，一个 UI 元素，用户可以在其中生成他们的网站并下载它；
CanvasService - 此服务协调网站的创建，并依赖于一组服务（NavbarService、HeroService、FooterService）；
DomService - 此服务负责在无样式的高层创建 DOM 元素；
ComponentService - 这些服务组（NavbarService、HeroService、FooterService）负责在较低级别创建 DOM 元素；
FontService - 此服务是 Google 字体存储库。
以上内容是我很快整理出来的，所以我知道它并不完美。在我走向生产化过程中，我还对项目的可扩展性方向有一些疑问。这些是我的问题：
我把它展示给别人看，他们说他们无法理解...因为听起来我的 CanvasService、DomService 和组件服务创建原始 HTML，所有这是描述 DOM 元素的模型。这似乎是非常错误的设计。我们开发服务的方式无法扩展或管理。如果不出意外，这是对open/closed原则的极端违反。它们最终将成为无法完全覆盖 DOM 元素所有功能的巨大“工厂”。 这是我最关心的问题。如何从架构的角度解决这个问题？
鉴于项目的性质，我正在大量处理原始 html。我混合使用多种方法来动态生成所需的 HTML。我想问一下以上是否可取。在架构上创建和管理 HTML 块的最简洁方法是什么？我应该使用原始字符串还是创建更定制的内容？
为每个组件（导航栏、英雄、页脚）存储各种样式然后随机应用它们的最佳方法是什么？据我了解，样式可以分为两类 - 模板和主题。一个模板可以有多个主题，一个主题可以关联多个主题。一个很好的例子是网站上的“light/dark”颜色模式。目前在 NavbarService 中，我将一系列可能的宽度和高度存储在一个数组中。
除了违反开闭原则（unknown unknown）之外，我当前的架构方法是否还会出现其他问题？过去，每当我开始这样的项目时，它们很快就会变得不可持续。我失去了兴趣，因为那时我正在与代码库搏斗。我希望这个过程继续愉快，并在整个项目过程中保持我的代码干净和可管理，并应用最佳原则。
此处提供示例演示：https://stackblitz.com/edit/angular-ivy-2pga8q（每次重新加载页面时，都会出现一个新的导航栏）。
这是一个有趣的问题。我也不太明白图表，但你的描述更有意义。
让我们暂时假设您生成的 HTML/CSS/JS 组件编写合理，并生成格式合理且合理的输出。在这一点上，您实际上并没有 'need' 来存储关于它的元数据，因为任何不需要的东西都会膨胀。您需要的是构建小型模块化代码块的能力，这些代码块可以在编辑或附加输入参数后再次重新编译。
为了支持这一点，我强烈建议将代码 (HTML) 的输出分离为带有版本标记的解决方案库 - 并且生成的代码应该是来自用户或数据输入。
创建一个简单的类比，想象一下公式 (8+1+1=10)。
在此示例中，输出 (10) 是您唯一需要 publish/present/store 的东西。但是，您需要保持起始数据 (8+1+1) 独立 - 主要是因为如果其中一个值发生变化（比如现在是 8+2+1），您现在可以使用新的输出重新生成第二个版本版本并获得新答案 (11)。
因此，与担心输出元素的 string/text 格式相比，我会更多地关注存储构建 blocks/wysiwyg/mark 组件。从架构的角度来看，如果您有任何持续需要 interact/modify 此代码，您需要关注易用性和可重用性。
还请记住，除非您正在创建天网，否则您就不是在编写 'code that writes code'。您正在编写代码来帮助人类编写代码。始终假设需要从外部来源进行干预和修改 - 专注于获取（算法 + 输入 = 输出）的模块化形式并存储过程和输入。如果你做对了，你可以随时出于任何原因重新生成输出。