动机
Feature-Sliced Design（特性分层设计）的主要理念是基于结合研究成果，讨论各种类型开发者的广泛经验，来促进和降低复杂项目开发的成本。
显然，这不会是万能的解决方案，当然，该方法论也会有自己的适用限制。
尽管如此，关于这种方法论整体可行性仍然存在合理的质疑。
更多详情在讨论中进行了探讨
为什么现有解决方案还不够？
通常会有这些论点：
- "为什么需要一些新的方法论，如果你已经有了长期建立的设计方法和原则，如
SOLID、KISS、YAGNI、DDD、GRASP、DRY等。"- "所有问题都可以通过良好的项目文档、测试和结构化流程来解决"
- "如果所有开发者都遵循上述所有原则，问题就不会发生"
- "一切都在你之前就被发明了，你只是不会使用它"
- "采用 {框架名称} - 那里已经为你决定了一切"
仅有原则是不够的
仅仅存在原则并不足以设计出良好的架构
不是每个人都完全了解这些原则，更少的人能够正确理解和应用它们。
设计原则过于宽泛，没有给出具体问题的明确答案："如何设计可扩展和灵活应用程序的结构和架构？"
流程并不总是有效
文档/测试/流程当然是好的，但遗憾的是，即使在它们上面投入高成本 - 它们也不总能解决架构提出的问题和新人加入项目的问题
- 每个开发者进入项目的时间并没有大幅减少，因为文档往往会变得庞大/过时
- 持续确保每个人都以相同方式理解架构 - 这也需要大量资源
- 不要忘记总线因子（bus-factor）
现有框架不能在所有地方应用
- 现有解决方案通常有很高的入门门槛，这使得寻找新开发者变得困难
- 此外，技术选择通常在项目出现严重问题之前就已经确定，因此你需要能够"使用现有的" - 而不被技术绑定
问："在我的项目
React/Vue/Redux/Effector/Mobx/{你的技术}中 - 我如何更好地构建实体结构和它们之间的关系？"
结果
我们得到了*"像雪花一样独特"*的项目，每个项目都需要员工长时间的沉浸，而这些知识不太可能适用于另一个项目。
@sergeysova: "这正是我们前端开发领域目前存在的情况：每个技术负责人都会发明不同的架构和项目结构，虽然这些结构不一定能经受时间的考验，结果是除了他之外最多只有两个人可以开发项目，每个新开发者都需要重新沉浸其中。"
为什么开发者需要这个方法论？
专注于业务功能，而不是架构问题
该方法论允许你节省设计可扩展和灵活架构的资源，而是将开发者的注意力引导到主要功能的开发上。同时，架构解决方案本身在项目之间是标准化的。
一个单独的问题是，该方法论应该赢得社区的信任，这样其他开发者可以熟悉它，并在他可用的时间内依靠它来解决他项目的问题
经过经验验证的解决方案
该方法论是为那些致力于设计复杂业务逻辑的经过验证解决方案的开发者而设计的。
然而，很明显，该方法论通常是关于一套最佳实践、文章，这些文章解决开发过程中的某些问题和案例。因此，该方法论对其他开发者也会有用 - 那些在开发和设计过程中以某种方式面临问题的人
项目健康
该方法论将允许提前解决和跟踪项目问题，而不需要大量资源
技术债务往往会随着时间的推移而积累，解决它的责任既在技术负责人身上，也在团队身上
该方法论将允许你提前警告项目扩展和开发中的可能问题。
为什么企业需要方法论？
快速入职
有了方法论，你可以雇佣一个已经熟悉这种方法的人到项目中，而不需要重新培训
人们开始更快地理解和为项目带来价值，并且有额外的保证为项目的下一次迭代找到人员
经过经验验证的解决方案
有了方法论，企业将获得系统开发过程中出现的大多数问题的解决方案
因为企业最常想要获得一个框架/解决方案，能够解决项目开发过程中的大部分问题。
对项目不同阶段的适用性
该方法论可以在项目支持和开发阶段以及MVP阶段为项目带来好处
是的，对于MVP来说最重要的是*"功能，而不是为未来奠定的架构"。但即使在有限的截止日期条件下，了解方法论中的最佳实践，你也可以在设计系统的MVP版本时"用很少的代价"*找到合理的妥协 （而不是"随机"建模功能）
测试也是如此
什么时候我们的方法论不需要？
- 如果项目只会存在很短时间
- 如果项目不需要支持的架构
- 如果企业不认为代码库和功能交付速度之间存在联系
- 如果对企业来说更重要的是尽快完成订单，而不需要进一步支持
企业规模
- 小企业 - 最常需要现成的和非常快速的解决方案。只有当企业增长（至少到接近平均水平）时，他才明白为了让客户继续使用，除其他外，有必要将时间投入到正在开发的解决方案的质量和稳定性上
- 中型企业 - 通常理解开发的所有问题，即使有必要*"安排功能竞赛"*，他仍然会花时间进行质量改进、重构和测试（当然 - 还有可扩展的架构）
- 大企业 - 通常已经有广泛的受众、员工和更广泛的实践集合，甚至可能有自己的架构方法，所以采用别人的想法对他们来说并不常见
计划
目标的主要部分在这里阐述，但此外，值得谈论我们对未来方法论的期望。
结合经验
现在我们正在尝试结合核心团队的所有多样化经验，并因此获得一个经过实践锤炼的方法论。
当然，我们可能最终得到Angular 3.0，但这里更重要的是调查设计复杂系统架构的根本问题
是的 - 我们对当前版本的方法论有抱怨，但我们希望共同努力达成一个单一和最优的解决方案（考虑到社区的经验等）
规范之外的生活
如果一切顺利，那么方法论将不仅限于规范和工具包
- 也许会有报告、文章
- 可能会有用于将根据方法论编写的项目迁移到其他技术的
CODE_MOD - 可能最终我们能够接触到大型技术解决方案的维护者
- 特别是对于React，与其他框架相比 - 这是主要问题，因为它没有说明如何解决某些问题