Следует ли при создании приложения с нуля начинать с объектно-ориентированной (ОО) модели или модели сущности-отношения (ER)?
Возможно, вы захотите соблюдать принцип отсрочки архитектурных решений как можно дольше. Мысль идет о том, что вы будете знать в будущем больше о своей проблемной области, чем сейчас, поэтому любые решения, которые вы принимаете сегодня, являются подозрительными.
Другим хорошим принципом в сочетании с этим может быть попытка сначала попытаться выполнить самые рискованные части ваших требований - мысль о том, что если вы выполняете легкие части, то обнаруживаете, что опасные части двигают вас в другом направлении, у вас нет переделать легкие части. Рискованное здесь означает то, что вы не знаете, как это делать.
Учитывая эти два, и учитывая то, что я часто пытаюсь подойти к вещам с точки зрения ОО, вы можете сначала попытаться начать с ОО-модели наиболее рискованных частей вашего приложения и реализовать наименьшее возможное количество кода, который может работать, удовлетворяющий рискованные требования. Затем начните расширять свою модель OO по мере необходимости, чтобы добавить функциональность, которая вам понадобится. В то же время вы можете полностью отложить принятие решения о том, использовать ли SQL или NoSQL, плоские файлы, облачное хранилище или что-то еще ... и вы можете в конечном итоге обнаружить, что вам вообще не нужен реляционный (устранение необходимости в модели ER).
Модель ER определяет, как будут сохраняться данные приложения, а модель OO решает, как эти же данные будут храниться в памяти или во время работы приложения. Таким образом, проектирование схемы базы данных (модель ER) и проектирование структуры класса (модель OO) являются связанными проектными соображениями, и о них обычно даже можно думать одновременно. Фактически, если вы используете инструмент объектно-реляционного отображения (ORM) , ваша модель ER и модель OO могут быть одинаковыми. Другими словами, ваши классы (модель OO) могут быть аннотированы таким образом, что они сами определяют модель ER.
Однако перед проектированием убедитесь, что у вас есть очень хорошее представление о реальных требованиях к программному обеспечению, для чего оно будет использоваться, как оно будет использоваться и кто будет его использовать. Многие разработчики начинают задумываться о проектных решениях, прежде чем они полностью понимают потребности продукта, и в итоге получают дизайн, который не подходит для истинной цели приложения.