替代方案
架构方法的历史
大泥球（Big Ball of Mud）
什么是大泥球；为什么它如此常见；何时开始带来问题；该怎么做以及FSD如何在这方面提供帮助
- (文章) Oleg Isonen - 在AI接管之前关于UI架构的最后话语
- (报告) Julia Nikolaeva, iSpring - 大泥球和单体的其他问题，我们已经处理过
- (文章) DD - 大泥球
智能和愚蠢组件（Smart & Dumb components）
关于这种方法；关于在前端的适用性；方法论立场
关于过时性，关于方法论的新观点
为什么容器组件方法是有害的？
设计原则
我们在谈论什么；FSD立场
SOLID、GRASP、KISS、YAGNI等 - 以及为什么它们在实践中不能很好地协同工作
以及它如何聚合这些实践
DDD
关于这种方法；为什么它在实践中效果不佳
有什么不同，如何改善适用性，在哪里采用实践
整洁架构（Clean Architecture）
关于这种方法；关于在前端的适用性；FSD立场
它们如何相似（对许多人来说），它们如何不同
- (讨论串) 关于方法论中的用例/交互器
- (讨论串) 关于方法论中的依赖注入
- (文章) Alex Bespoyasov - 前端的整洁架构
- (文章) DDD、六边形、洋葱、清洁、CQRS等...我如何将它们整合在一起
- (演讲) Ilya Azin - Feature-Sliced Design（关于整洁架构、DDD的片段）
- (文章) 整洁架构的误解
框架
关于在前端的适用性；为什么框架不能解决问题；为什么没有单一方法；FSD立场
框架无关，约定方法
原子设计（Atomic Design）
什么是原子设计？
在原子设计中，职责范围被划分为标准化的层级。
原子设计分为5个层级（从上到下）：
pages（页面）- 功能类似于FSD中的pages层。templates（模板）- 定义页面结构而不绑定到特定内容的组件。organisms（有机体）- 由分子组成并具有业务逻辑的模块。molecules（分子）- 通常不包含业务逻辑的更复杂组件。atoms（原子）- 没有业务逻辑的UI组件。
一个层级的模块只与下面层级的模块交互，类似于FSD。 也就是说，分子由原子构建，有机体由分子构建，模板由有机体构建，页面由模板构建。 原子设计还意味着在模块内使用公共API来实现隔离。
对前端的适用性
原子设计在项目中相对常见。原子设计在网页设计师中比在开发中更受欢迎。 网页设计师经常使用原子设计来创建可扩展且易于维护的设计。 在开发中，原子设计经常与其他架构方法论混合使用。
然而，由于原子设计专注于UI组件及其组合，在架构内实现业务逻辑时会出现问题。
问题在于原子设计没有为业务逻辑提供明确的职责级别， 导致业务逻辑分散在各种组件和级别中，使维护和测试变得复杂。 业务逻辑变得模糊，使得难以清楚地分离职责，并使代码变得不够模块化和可重用。
它与FSD的关系如何？
在FSD的上下文中，原子设计的一些元素可以应用于创建灵活且可扩展的UI组件。
atoms和molecules层可以在FSD的shared/ui中实现，简化基本UI元素的重用和维护。
├── shared
│ ├── ui
│ │ ├── atoms
│ │ ├── molecules
│ ...
FSD和原子设计的比较显示，两种方法论都追求模块化和可重用性， 但专注于不同的方面。原子设计面向视觉组件及其组合。 FSD专注于将应用程序功能划分为独立模块及其相互连接。
功能驱动（Feature Driven）
关于这种方法；关于在前端的适用性；FSD立场
关于兼容性、历史发展和比较