С первым решением соглашусь с некоторой оговоркой - оно применимо для версионных СУБД, но чревато ударом по производительности для блокировочных.
Со вторым сложнее. Ваш пример написан в парадигме "плевать на хранилище, сначала доменная модель", поэтому он прекрасно валидируется и покрывается тестами, но при попытке впихнуть модель в БД начинаются танцы с бубном - либо надо вычитывать весь стадион ради бронирования одного места, либо городить ленивую загрузку (что может быть весьма нетривиально, если хотим оставить модель чистой), либо все же адаптировать модель под хранилище (чего мы старательно избегали).
Первый. Клиент Вася выбирает место 25 для бронирования, клиент Петя выбирает место 25 для бронирования - оба видят экземпляры класса FreeSeat. Вася бронирует и получает подтверждение, Петя бронирует и тоже получает подтверждение. Как объяснить Васе, что в кино он сегодня не идёт?
Второй. Приложение работает в проде, но клиенту надо то же самое, только не для кинотеатра на 150 мест, а для стадиона тысяч на 15 человек. Логика бронирования и покупки аналогичная. Завели в БД места, но вот незадача - теперь для бронирования одного места мы выкачиваем из БД 15к строк. DBA заходит в наш офис, у него в руке дробовик.
Безусловно, нормальные коммуникации могут повысить эффективность работы, но в случае разработчиков коммуникации - это опция. И касаться они должны, как мне кажется, обмена опытом и практиками, но никак не выяснения или постановки задачи.
По-хорошему есть запрос на изменение, ТЗ или еще какой-то документ, содержащий четкое описание того, что нужно сделать, и как должно получиться в итоге, и этой информации разработчику достаточно. Если этот документ не составили или составили левой ногой в надежде, что разработчики как-то сами разберутся, это значит, что кто-то не сделал свою работу и переложил ее на разработчика, который теперь должен (на самом деле нет) устраивать какие-то там коммуникации.
Подход в стиле менеджера, считающего себя эффективным - коммуникации, договоренности, чатики какие-то. Я как разработчик вижу только то, что оформлено надлежащим образом в виде запросов на изменение в джире/тфсе или где-то еще, плачу Ярославны в чатике могу только посочувствовать. Далее, если запрос на изменение оформлен, не в моей компетенции обсуждать его целесообразность: сказано перекрасить кнопку - перекрашиваем.
Дергать коллегу с вопросом "как это работает" считаю допустимым только в самом крайнем случае, когда чтение кода и документации, отладка и гугление не помогли. Коллега - он тоже программист, а не нянька.
С первым решением соглашусь с некоторой оговоркой - оно применимо для версионных СУБД, но чревато ударом по производительности для блокировочных.
Со вторым сложнее. Ваш пример написан в парадигме "плевать на хранилище, сначала доменная модель", поэтому он прекрасно валидируется и покрывается тестами, но при попытке впихнуть модель в БД начинаются танцы с бубном - либо надо вычитывать весь стадион ради бронирования одного места, либо городить ленивую загрузку (что может быть весьма нетривиально, если хотим оставить модель чистой), либо все же адаптировать модель под хранилище (чего мы старательно избегали).
Примеры из жизни.
Первый. Клиент Вася выбирает место 25 для бронирования, клиент Петя выбирает место 25 для бронирования - оба видят экземпляры класса FreeSeat. Вася бронирует и получает подтверждение, Петя бронирует и тоже получает подтверждение. Как объяснить Васе, что в кино он сегодня не идёт?
Второй. Приложение работает в проде, но клиенту надо то же самое, только не для кинотеатра на 150 мест, а для стадиона тысяч на 15 человек. Логика бронирования и покупки аналогичная. Завели в БД места, но вот незадача - теперь для бронирования одного места мы выкачиваем из БД 15к строк. DBA заходит в наш офис, у него в руке дробовик.
Безусловно, нормальные коммуникации могут повысить эффективность работы, но в случае разработчиков коммуникации - это опция. И касаться они должны, как мне кажется, обмена опытом и практиками, но никак не выяснения или постановки задачи.
По-хорошему есть запрос на изменение, ТЗ или еще какой-то документ, содержащий четкое описание того, что нужно сделать, и как должно получиться в итоге, и этой информации разработчику достаточно. Если этот документ не составили или составили левой ногой в надежде, что разработчики как-то сами разберутся, это значит, что кто-то не сделал свою работу и переложил ее на разработчика, который теперь должен (на самом деле нет) устраивать какие-то там коммуникации.
Подход в стиле менеджера, считающего себя эффективным - коммуникации, договоренности, чатики какие-то. Я как разработчик вижу только то, что оформлено надлежащим образом в виде запросов на изменение в джире/тфсе или где-то еще, плачу Ярославны в чатике могу только посочувствовать. Далее, если запрос на изменение оформлен, не в моей компетенции обсуждать его целесообразность: сказано перекрасить кнопку - перекрашиваем.
Дергать коллегу с вопросом "как это работает" считаю допустимым только в самом крайнем случае, когда чтение кода и документации, отладка и гугление не помогли. Коллега - он тоже программист, а не нянька.