#otus #deepwebdev Представьте, что вы разрабатываете модель данных для вашего приложения. Дело ответственное: скоро модель обрастёт другим кодом и для изменения модели придётся переписывать существенную часть приложения. Ошибки при проектировании модели дорогого стоят.
Рассмотрим несколько правил, которые позволят снизить количество ошибок.
Во-первых, лучше использовать названия из предметной области для моделей и полей. Так, чтобы эксперт в предметной области смог всё понять. О том, как работает приложение этому эксперту знать не нужно: до бизнес-логики дело пока не дошло.
Во-вторых, не стоит придумывать новые сущности для упрощения модели. Иногда хочется придумать промежуточную сущность, которая не имеет смысла в предметной области, но позволяет проще уложить данные в хранилище. Это почти всегда плохая идея: новый термин начинает плохо дружить с существующими сущностями, а при реализации бизнес-логики приходится добавлять всё новые и новые костыли. Не говоря уже о том, что придётся всем объяснять смысл нового термина.
В-третьих, не нужно упрощать связи. Если у поста может быть много авторов, не надо делать одного потому что в сервисе предусмотрен только один автор. Завтра это требование поменяется и жизнь существенно усложниться. А пока не поменялось, количество лишнего кода можно существенно сократить, но не на уровне модели.
Выше перечислены три самые частые ошибки при формировании модели данных. Эти же утверждения лежат в основе Domain Driven Design.
Рассмотрим несколько правил, которые позволят снизить количество ошибок.
Во-первых, лучше использовать названия из предметной области для моделей и полей. Так, чтобы эксперт в предметной области смог всё понять. О том, как работает приложение этому эксперту знать не нужно: до бизнес-логики дело пока не дошло.
Во-вторых, не стоит придумывать новые сущности для упрощения модели. Иногда хочется придумать промежуточную сущность, которая не имеет смысла в предметной области, но позволяет проще уложить данные в хранилище. Это почти всегда плохая идея: новый термин начинает плохо дружить с существующими сущностями, а при реализации бизнес-логики приходится добавлять всё новые и новые костыли. Не говоря уже о том, что придётся всем объяснять смысл нового термина.
В-третьих, не нужно упрощать связи. Если у поста может быть много авторов, не надо делать одного потому что в сервисе предусмотрен только один автор. Завтра это требование поменяется и жизнь существенно усложниться. А пока не поменялось, количество лишнего кода можно существенно сократить, но не на уровне модели.
Выше перечислены три самые частые ошибки при формировании модели данных. Эти же утверждения лежат в основе Domain Driven Design.