Очевидно, вы получите много разных ответов на этот вопрос, но я склонен сначала думать о базе данных, а затем строить объекты на основе этого. Я думаю, что моему мозгу проще работать таким образом, поскольку я могу визуализировать схему базы данных (а также очень легко показать отношения в схеме базы данных). @Tdpi прямо здесь: вы должны проектировать на основе проблемной области - для меня это означает мышление в базе данных, но для разных людей оно разное.
Отношения между объектами не всегда так очевидны, и поэтому сложнее нарисовать диаграмму, которая показывает их отношения. Наличие объектов, наследуемых друг от друга (но, возможно, с использованием одних и тех же таблиц на стороне базы данных), может еще больше запутать. Тем не менее, в некоторых сложных приложениях я выполнял оба одновременно - например, создавал таблицу и в то же время создавал структуру объектов, в которой несколько объектов наследуют одну и ту же базу, и все используют одну и ту же таблицу.
Другим аргументом для DB-first является то, что большинство слоев ORM, как правило, генерируют объекты на основе схемы базы данных, поэтому, если вы проектируете объекты, затем попытаетесь выполнить обратный инжиниринг базы данных, а затем позвольте ORM генерировать объекты, вы добры делать вещи задом наперед и почти наверняка не получится в точности с тем, что вы спроектировали вначале на бумаге.
Если вы используете ORM, который генерирует базу данных для вас на основе объектов, то, вероятно, имеет смысл сделать это наоборот, и сначала спроектировать ваши объекты. Пока вы правильно моделируете проблемную область, менее важно, если вы сначала строите базу данных или объекты.
Все это говорит о том, что когда я проектирую интерфейсную часть приложения, я создаю его карандашом и бумагой и даже не думаю о том, как данные хранятся в серверной части. (объекты, база данных или что-то еще). Я просто проектирую интерфейс так, как я хочу, чтобы он выглядел и работал.
Затем следующей задачей является подключение этого пользовательского интерфейса к базовой схеме, которая иногда очень проста, а иногда и не так проста - но я обнаружил, что именно так создаются лучшие пользовательские интерфейсы. Часто я не раскрываю всю функциональность или разрешаю настраивать только простые настройки (например, разрешать применение только разрешений, даже если серверная часть также позволяет запретить разрешения на наследование). Это означает, что ваш пользовательский интерфейс не слишком сложен, или, по крайней мере, проще создать первую версию, но вы также не застряли с созданием ограниченного бэкенда или с необходимостью радикально изменить его в будущем.
Когда вы создаете пользовательский интерфейс на основе того, как хранятся данные или созданные вами объекты, он, как правило, выглядит именно так - пользовательский интерфейс, разработанный программистом.