在开始或规划一个新项目时，您是否总是倾向于考虑 db 架构，或者您是否采取相反的方式开始设计 UI，然后向下移动？
或者你有不同的发展方式？
并不是真正的敏捷/瀑布/规格/故事问题，只是一种了解人们在从事个人/专业或其他项目时倾向于哪种方式的方法。
我认为这两种方法都是过去最好的方法，目前我处于 UI 第一阵营，但这种情况可以而且将会改变！
干杯 约翰
【问题讨论】：
标签： user-interface database-design architecture
对于普通用户而言，用户界面就是软件。他们不关心数据的存储方式、您使用的平台等。因此，如果您的软件将被人们使用，我强烈建议从 UI 开始——原型或模型。向用户展示并获得反馈。然后建立业务层和数据层。
我发现这有助于收集需求。非技术用户更有可能告诉您“哦，等等，我们需要此页面上的另一个字段”而不是“我们需要此表模式中的另一个属性”。他们也可能会说“我们这里需要另一个按钮”，这通常会转化为一些额外的业务逻辑等。
【讨论】：
我两者都做。我通常会画出屏幕外观的原型，然后尝试从中开发数据模型。我发现这不是直接进入数据库，而是与我的 UI 一样工作得更好，我可以看到对属性（或数据库中的字段）的需求，否则我不会想到。然后我从那里开发模型并来回反弹，直到两者都满足需求，然后我担心数据库模式。通常，虽然模型本身会为我定义架构，但我们已经处理好了。
【讨论】：
这似乎是非常情境化的。在我所做的工作中，大部分工作都是从数据库开始的，因为我处理的数据库是企业资源——它们被多个 UI 使用。围绕可能经常变化的特定 UI 的变幻莫测设计 DB 是有害的。
另一方面，在某些情况下，将注意力集中在 UI 上可能更有益，而让数据库设计稍后进行 - 例如，可能在嵌入式 DB 移动应用程序中。
【讨论】：
首先布置你的屏幕，这样你就知道你在数据库中需要什么。
如果您从数据库开始，那么您通常会从一组关于应用程序如何运行的假设开始。
【讨论】：
我倾向于从中间开始，弄清楚应用程序将做什么以及如何做，然后在 UI 和数据库设计之间来回切换，因为它们可以相互通知。
【讨论】：
一般来说，我先从数据库开始，然后构建适合它的 UI。通常会有一些反复，因为我可能需要更改数据库以适应 UI 的要求，反之亦然。
这条路线，首先从数据库开始，是我在学校的教学方式，并一直坚持下去。
与我一起工作的一位程序员将从输出开始。他首先要弄清楚需要做什么（即需要发布哪些报告等），然后研究需要哪些数据才能到达那里。 UI 和数据库是同时构建的。
【讨论】：
在我从事的项目中，我发现 UI 是我的许多需求的来源——它是最终用户关心（或至少考虑）的部分。
【讨论】：
基本上，我首先要找出功能应该是什么。我不处理 UI 或它的外观或它应该如何输入，我处理的是用户想要做什么。
然后我围绕它构建了一个数据模型。有时它是一个非常简单的数据模型（特别是如果它是一个简单的需求，例如“播放电影”），有时它非常复杂。
只有在做出决定之后，我才会尝试设计一个既反映模型又反映用户期望输入工作方式的 UI。
随心所欲；它对我来说相当有效。
【讨论】：
最重要的是，首先要专注于确保系统能够解决它打算解决的问题。
收集需求以定义工作流程、数据、复杂的用户交互等，然后从那里开始构建。
当然你总是需要在这里和那里调整一些东西，但是根据我的经验，我发现那些订阅一种或另一种哲学的人（即总是从 db 开始并建立与 ui 并向下潜入）很多次最终会得到一个不适合问题的解决方案。
【讨论】：
首先为域建模 - 这将告诉您如何构建数据库。接下来找到您的需求——用户需要对应用程序做什么？这将告诉您需要存在哪些功能。有了这些，您就可以创建数据库模式和软件模型（无论是面向对象的、功能的还是其他的，您都将获得必要的信息）。然后制作一个漂亮的 UI 来展示您构建的功能 - 当然，UI 构建也可以与功能同步完成，但两者都应该在确定域的外观之后进行。 p>
【讨论】：
我最近刚停止设计我的数据模型。我与一位开发人员一起工作，让我开始使用领域驱动设计。我现在坐下来先设计我的领域模型，然后再设计我的数据模型。同时，我考虑了 UI 可能带来的任何挑战。
【讨论】：