nirvimel

Редкий случай, когда данные сходу представленные почти в нормальной форме, следовательно идеально вписываются в одну таблицу БД.
Только поля с перечисляем типом (например, у вас "Тип размещения"), конечно, нужно сделать ключами ко внешним таблицам (ну, это очевидно).
Единственное исключение - "Спальные места" должны идти в отдельной таблице и подключаться к основной таблице как Много-к-одному, так как их количество переменно, а сами они представляют отдельный тип данных. Ну и комменты (если храните их), то, очевидно, пойдут через Много-к-одному.

Несколько банальных принципов ООП (применительно к вашему проекту):
Сущности, которых касается определенный запрос, должны быть либо унаследованы от одного класса, либо реализовывать один интерфейс (в дополнение к другим интерфейсам), который имеет методы управления этими сущностными, необходимые для реализации этого запроса.
Запросы также должны быть сгруппированы в дерево классов или наследовать набор интерфейсов. Сущности могут взаимодействовать не с конкретными классами запросов, а с общими интерфейсами, которых не так много, как различных запросов.
То же самое с realtime обработчиками и, вообще, с любыми элементами логики.

1. Стив Макконнелл - Совершенный код.
- почему еще никто не назвал эту очевидную классику? (я аж Ctrl+F-нул по странице, не поверил сначала).
- также рекомендую его "Анализ алгоритмов. Вводный курс" (хоть это и в стороне от сабжа).

2. Кент Бек - Экстремальное программирование. Разработка через тестирование.
- многие считают этот подход антипаттерном, но прочесть, безусловно, стоит хотя бы ради того, чтобы иметь возможность самому поискать ошибки в рассуждениях автора (оно того стоит).

Еще несколько очень разных книг, которые для меня стоят в одном ряду с Макконнеллом:
3. Фредерик Брукс - Мифический человеко-месяц.
4. Эндрю Хант, Дэвид Томас - Программист-прагматик. Путь от подмастерья к мастеру.
5. Том Демарко, Тимоти Листер - Человеческий фактор: успешные проекты и команды.

Далее, у Макконнелла в (1) после каждой главы приведен огромный список литературы по теме, большая часть - признанная классика, можно прямо брать списком и выкладывать в этот тред.

Как устроена архитектура P2P приложений?

Идея, на которой построено большинство P2P сетей называется DHT (Distributed hash table) (рус), эталонной реализацией этой идеи является Kademlia (рус).

Каждому клиенту будет необходимо узнать адреса других клиентов. Как они смогут получить друг у друга актуальный список?

Не существует никакого общего списка, в котором были бы перечислены все пиры сети. Невозможно мгновенно (за один запрос) получить информацию об интересующем пире (существует ли он вообще? активен ли? каков его реальный IP для подключения), но эту информацию можно достать из сети за несколько запросов: Кто знает Х? Кто знает кого-то, кто мог бы знать X? Кто знает кого-то, кто мог бы знать кого-то, кто мог бы знать X? и.т.д.

Если приложение действительно децентрализованное, у него ведь не должно быть какого-то пира, который всегда будет знать список более актуальный, чем другие, верно?

Именно так.

Или всё таки, должны быть в сети какие-то доминирующие пиры?

Не доминирующие, а правильнее сказать "первоначальные", чьи адреса жестко прописаны в каждом экземпляре клиентского софта. Они обеспечивают так называемый bootstrap новых пиров при их первом заходе в сеть. В дальнейшем, находясь в сети, пир держит в памяти необходимый набор маршрутов (очень небольшую долю от всей сети) для поддержания контакта с сетью и больше не нуждается в наличии и функционировании "первоначальных".

Тогда если они разом каким-то образом падают, вся система должна сама выбрать других доминантов?

Их падение никак не повлияет на функционирование сети и уже подключенных к ней пиров. Но новые пиры "по холодному" не смогут подключиться никак, если ни один из "первоначальных" пиров не будет доступен.