Общий общий подход, которому я всегда стараюсь следовать, - это начать с разработки моделей предметной области. Это ваш «вездесущий язык», который будет определять бизнес-объекты и концепции, содержать бизнес-логику (позже, когда она у вас есть) и, как правило, будет общим языком, используемым в различных частях системы.
Идея состоит в том, что это должно быть понято (или, по крайней мере, понятно) всеми участниками. Например, некоторый менеджер в каком-то другом отделе не обязательно поймет реляционные базы данных или что-то еще о сохранении данных своего отдела в нем. Но он понимает бизнес-процесс своего отдела. Их родной язык, их концепции, их взаимодействия и т. Д. Вездесущий язык - это общий язык, который разделяют группы.
Во время этого процесса вы должны держать свои зависимости перед собой. Самым большим из них обычно является постоянство данных. Существует своего рода золотая мечта, чтобы доменные модели были невежественными или невежественными в целом, а для разделения интересов это хорошая вещь. Однако истинное невежество зависимостей может загнать вас в угол. Вы можете столкнуться с некоторыми серьезными проблемами производительности или архитектурными проблемами, которые впоследствии потребуют значительных изменений в дизайне.
Поэтому время от времени отказывайтесь от моделирования предметной области, чтобы думать о постоянстве (и других внешних зависимостях, таких как внешние службы, которые необходимо использовать, или сторонние приложения, которые необходимо интегрировать). При моделировании домена убедитесь, что модель по-прежнему работает должным образом со всем необходимым. Возможно, вам придется немного пойти на компромисс с вездесущим языком, чтобы приспособиться к ограничениям зависимости.
По сути, спроектируйте модель предметной области, прежде чем разрабатывать базу данных. Но не забывайте о базе данных во время этого процесса.