设计系统时，最好的做法是围绕您将要使用的框架进行设计吗？

在开发计划与某个框架一起使用的系统或应用程序时，最好的做法是在不考虑框架的情况下设计系统，还是最好以一种思维定势来设计系统，“那么框架将拥有更轻松的时间有了这个”。

您的设计应尽可能满足客户的需求。请记住，设计中包含一些小东西，例如：

• 用户体验
• 功能性
• 您的应用程序各部分如何通信（与自身或与外部实体）

这些事情都不应该由框架决定。如果很明显您将为实现这些目标而奋斗，那么您可以选择一个新的框架来帮助您在开始编写代码之前实现这些目标。

一旦选择了适当的工具集（框架是一种工具），我建议以设计使用方式使用这些工具。您偏离框架设计的距离越远，您为团队增加的学习曲线就越大，出现问题的机会就越大。

简而言之

• 为您的用户设计
• 选择合适的工具来完成您的设计
• 以设计使用方式使用工具

进一步的想法：

经过20多年的软件工程工作，并使用了多个框架，我学到了两个教训。所有框架都是一把双刃剑：它们既约束又使能。在查看上面提到的三大要素之前确定框架的问题是，对于中等（最好）的用户体验，您可能会损害良好的用户体验。否则您可能被迫偏离框架设计以完成某些特定功能。

框架自然会影响特定模块和子系统（例如GUI前端）的设计。正如提到的其他答案一样，如果您发现自己与所选框架作斗争，将会遇到困难。

但是，更广泛地讲，您应该避免让任何单一框架或技术支配或驱动整个系统架构的“大局”。大多数通用应用程序框架都不鼓励这样做，因此，如果您发现自己围绕一个框架编写整个系统，那么您可能正在做该框架的作者所不打算做的事情。

您可能会使用许多不同的框架来解决不同的问题。随着系统变得越来越复杂，您需要注意不要构建“泥泞的大球”。尽可能使您的系统保持模块化和松散耦合。通过编写包装程序和适配器将某些框架“隐藏”在远离其他组件的位置，可以更好地将某些框架置于抽象之后。GUI工具包往往只提供前端GUI功能，因此，这些GUI模块应远离系统的其余部分。

通用框架（例如UI框架，数据层框架等）不存在来规定系统的完整体系结构-最多它们可能会规定组件或模块的设计；例如，某些GUI技术针对特定的MV *模式。

系统的整体体系结构应主要由业务需求决定。您可能会发现自己严重依赖特定工具（例如，消息中间件工具或ORM框架）来将所有内容绑定在一起，但是如果您已将框架封装在诸如“服务”类的抽象中，遇到框架的局限性时，您不太可能发现自己受到该框架的束缚。

在进行大图设计时，请谨记以下几点：

• 旨在构建模块化软件
• 编写每个模块和组件时，请考虑关注点分离
• 考虑多层体系结构以将系统分为多个层
• 不要建立泄漏的抽象
• 此相关问题的首字母缩写：什么是DRY，KISS，SOLID等分类？

是的，您应该尽可能地遵循框架“告诉”您要做的事情。

原因很简单，您越是坚持使用框架的“思考”方式，就越容易与其他开发人员讨论也使用该框架的问题/想法。

对于以后使用它的其他人，可以提高互操作性和易用性，如果您坚持使用所使用的任何东西的基本哲学，那么您将更好地理解和合并教程或常见的解决方案。

我能想到的是为什么您会“破坏”框架的唯一很好的理由是，鉴于其“默认”配置/原理的应用，您绝对需要它无法提供的功能。但是，那可能不是一个合适的框架。

基本上，这也可以应用于其他决策。您应该尽可能地使用所要使用的语言，因为如果您与其他人使用相同的语言，这会使事情变得更容易。