Добрый день! DomainModel можно располагать и в отдельном слое (это уже шаг в сторону "луковичной" архитектуры (onion). Например, если доменная модель сильно совпадает с моделями в DAL, то имеет смысл расположить ее в отдельном проекте VS, навесить атрибуты Column, Key, ForeignKey, NotMapped (и др. атрибуты из DataAnnotations) - это в случае, если у Вас EF CodeFirst (с EF Database first такое особо не прокатит - только через partial-классы, но, на мой взгляд, это "уродство"), после чего в слое DAL останется только функционал подключения к БД и выполнения запросов. Если доменная модель сильно различается от модели DAL, то можно написать всякие обертки, которые будут преобразовывать классы доменной модели в модели DAL и наоборот.
Я бы советовал доменную модель выносить в отдельный проект. Почему? Потому что так ею проще пользоваться. Иначе Ваш бизнес- или DAL-слой превратится со временем в помойку: там будут и атрибуты, и исключения, да еще в каждом слое свои, и enum, и всякие сервисы/менеджеры/хелперы/... При разбиении решения на проекты, на мой взгляд, также следует придерживаться принципа единственной ответственности (S из SOLID). Каждый проект отвечает за что-то одно. Это позволяет спокойно подключать/отключать функциональности из других проектов (получается что-то вроде модульности решения) и избавляет от циклических зависимостей между проектами (когда у Вас есть проект MyApp.Common, который подключен в MyApp.BLL, но в слое MyApp.BLL есть функционал, который нужно использовать внутри проекта MyApp.Common => получается циклическая зависимость, и способ ее решения - перенести общий функционал в отдельный проект).
