Это просто мнение.
Доменные объекты являются частью бизнеса.То же самое для контекстов и хранилищ.
На самом деле, я хочу сказать, что OR / M - это абстракция над реляционной базой данных или другими типами хранилищ, поэтому они могут выступать в качестве объектно-ориентированного хранилища.
Это OR / M отбрасывает уровни данных в современных программных решениях.
Репозитории, контекст домена, объекты домена являются частью бизнес-уровня.
Единица работы - это программное обеспечениешаблон проектирования, и он предназначен не только для работы с базами данных или уровнем данных, но и может управлять многими вещами, такими как сетевые транзакции.Я бы посоветовал включить его в какое-то пространство имен, например "YourCompany.YourProject.Patterns.UnitOfWork" или что-то в этом роде.
Служба не имеет ничего общего с данными.Я хотел бы предложить пространство имен «YourCompany.YourProject.Services».
Еще один момент - ваши POCO, похоже, тоже работают как DTO, потому что вы используете везде, даже для передачи данных через слои и / илиярусы.Это может быть хорошо в реализации голых объектов или чего-то в этом роде, но вам нужно обратить внимание на факт использования объектов домена в качестве DTO, потому что они могут содержать свойства, информацию, поведение или OR / M прокси скрытых членов, которые могутвлияет на вес объектов - использование памяти -.
Принимая во внимание последний абзац, я бы посоветовал вам работать с DTO на любом уровне бизнеса, чтобы ваши службы возвращали DTO с определенным диапазоном свойств, которыеПотребители услуг должны будут нормально работать.
DTO, реализации шаблонов и подобные вещи, используемые во всех проектах, часть вашего решения должна находиться в каком-то проекте под названием «YourProject.Shared», и эта сборка не должна ссылаться налюбой слой: он должен оставаться нейтральным по отношению к слою, поэтому ссылка на него везде не обязывает иметь бесполезные зависимости.
Ну, это мое мнение и способ работы в моих проектах.