Как общая мысль, применяй разделяй и властвуй. Всегда.
Например, как вы думаете, почему конкретный клиент должен иметь возможность иметь «количество комнат» в течение определенного промежутка времени? Что если, например, я нахожусь в командировке и через несколько дней моя семья последует за мной. Теперь для заданного промежутка времени количество комнат больше не является постоянным.
Это не имеет значения? Правда, вы могли бы просто добавить еще одну запись для того же клиента. Но опять же, вы могли бы сделать это в первую очередь и упростить свою логику, говоря, что клиент может иметь только одну комнату за раз в одной строке, но могут быть строки, которые создают перекрытия во временных интервалах для данного клиента.
Кроме того, убедитесь, что вы разделяете Reservation и ReservationRequest. Я думаю, что последний состоит из набора оговорок - потому что я хочу, чтобы эта комната была для меня и моей семьи, и оба критерия должны быть согласованы.
Всего несколько идей. Обратите внимание, что это подход к башне из слоновой кости, и он может привести к массовым раздутым решениям. В RealWorld ™ придерживайтесь предложений Marcs: анализируйте фактические потребности клиентов. Если обработка 1% запросов увеличивает время разработки на 200%, ему это не понравится (или не понадобится), и наоборот.