在描述应用程序时，您经常遇到所谓的“框架问题”。域？

Question

你是否在现实世界的任务中经历过这样的压力？你是如何摆脱它的？

我希望我的问题没问题，否则请随时关闭。

Answer 1

我对“框架问题”的理解是，它与不再需要陈述关于世界运作方式的隐含假设有关。在给定的示例中here移动对象不会改变其颜色，绘制对象不会移动它。那些熟悉现实世界的人“明显”，但写下这样的假设是乏味的。 [然后我们将一个物体移动到油漆区，然后！它的颜色改变了。]

我想说，同意“显而易见”的问题是每次需求收集工作的特有问题。商务人士没有说明特殊情况，因为很明显......他们甚至不知道这是一个特例。

因此，我们作为软件生产者的工作是进入参考框架，真正理解问题领域。这很难。我会说，对于大部分项目来说，不正确理解的要求是一个非常严重的问题。伟大的分析师非常善于梳理细节。

Answer 2

我对App的看法。域由“数据建模”术语“框架”。

数据建模鼓励从以数据为中心的框架中查看问题域。我非常喜欢以数据为中心查看数据，但了解这种方法的局限性非常重要。

问题域不仅包括数据，还包含对该数据的操作。换句话说，它包括状态和行为。在传统的数据库设计项目中，数据和操作在需求收集级别进行分割。

数据分析产生数据的概念模型（通常以ER图和/或模型的形式表示）。动作分析产生App的功能规范。或应用程序的集合。那些将要使用的数据。

应用程序和数据的逻辑设计通常单独进行。应用程序的逻辑设计。通常使用面向对象的设计，它以某种方式构建事物。数据库的逻辑设计通常使用数据的关系模型，它以非常不同的方式构建数据。

稍后，当需要实施时，程序员将面临“对象 - 关系阻抗不匹配”。关于这一点已经写了很多。查看这种不匹配的一种方法是将两个不同的框架作为一个整体应用于需求。

上述内容只是触及你问题的表面，但这是一个开始。