举例来说，我们正在获取一个与数据库交互的Web应用程序项目。

我们如何开始开发？我们是从设计数据库，绘制简单的ERD并编写创建脚本开始的吗？我们是从设计Web应用程序的外观开始(也许使用photoshop)，然后为其创建母版页吗？还是从设计外观最小的领域模型开始，然后再应用更精美的设计？

请分享我们对此的想法...干杯...

解决方案

我倾向于采用这些想法中的最后一个，"首先以最小的外观设计域模型，然后再应用更精美的设计"。花时间使它看起来很漂亮。

首先弄清楚用户如何与网站进行交互。他们需要实现什么？

让此定义ERD，数据库模型将快速遵循。

然后，当我们真正开始编码时，我们将朝着正确的方向前进。

许多人还会说，首先编写单元测试。很难做到，但往往值得。

我们首先要确定以哪种方式开始。不，但实际上，要获得一个普遍的答案取决于太多的因素。我们是否使用敏捷开发的概念进行开发，是否有指定的功能设计，客户是否对我们提出了严格的要求，经验是什么？

通常，我们首先要开发业务对象，然后使用示例数据/伪数据库甚至有时是纯文本文件为它们创建视图。从那里开始，我们开始填充点点滴滴。如果未满足所有要求，则最好将数据库尽可能长时间地保留在开发范围之外。这样，我们就不必每次都更改数据库，存储过程以及与数据库的交互。

UI和DB，但这取决于哪个是真正的第一个。 UI非常重要，因为客户最终必须使用它(有人说有些开发人员有时会忘记...)。数据库设计是将(某些)结构置于所有业务需求中的好方法，而这些业务需求并非总是以严格且结构良好的方式指定的。

这是大三的经验，我从2004年开始从事开发工作，最初在一家开发公司工作了4年。

干杯，
马蒂亚斯

我从功能UI开始，从那里移动到业务层和db(通常是一开始就串联在一起)。客户通常会在某种程度上提供设计，因此我会尽早应用它，而不会妨碍它。我喜欢一步一步地整理完域(稍后可以接受较小的更改)，然后在代码中创建脚本时就创建了脚本。

听起来有点不合常规，但对我有用。

我绝对从UI原型开始。
客户直到看到他们才知道自己真正想要的是什么。

对UI的简单更改可以转化为系统核心组件的重大更改。因此，宁可让用户玩一个漂亮的原型，直到他们确信自己所要的是它，然后再深入研究系统对象和数据库设计。

关于数据库和系统对象，我发现很难决定要走的路。首先进入数据库肯定会影响我的课堂设计，因此我尝试尽可能先进入对象。它变成了更人性化的设计IMO

取决于项目ID'说。
通常，最好有一个Photoshop样机来向客户展示他们所得到的东西。

在小型免维护项目中，我首先尝试对数据库建模，以更好地了解结构。然后，通常很容易围绕它创建一个Web应用程序。

在较大的项目中，我通常从创建软件关键部分的(基本)原型开始。然后，我将这些展示给客户，然后将它们扔掉。他们只是来帮助我更好地了解即将到来的挑战。

但是，正如所说，这是一个品味和项目问题。