Борьба с именами в DDD; как назвать мои сервисы и объекты на внешних уровнях? ⇐ C#

[Anonymous]

Я пытаюсь создать чистую структуру проекта API, основанную на принципах DDD.
На данный момент у меня есть:

• Project.Api: конечные точки REST, контроллеры и Program.cs для конфигурации DI.
• Project.Domain : Чистая бизнес-логика, соответствующая правилам, предоставленным бизнес-командой.
• Project.Dal: EntityFramework и вся база данных связанные вещи.
• Project.Application: более высокий уровень, призванный связать домен, Dal и внешние уровни, такие как Grpc. /

  Код: Выделить всё

  Api

  конечные точки.
• Project.Grpc: Используя protobuf.net-grpc, этот проект реализует службы grpc, которые взаимодействуют с приложением. Уровень .
• Project.Contracts: Используя действие при сборке, этот проект автоматически генерирует файлы .proto в соответствии с структура и имя слоя Gprc.

В качестве конкретного примера предположим, что у меня есть два бизнес-объекта с именем Пользователь и Роль. Эти сущности определены в проекте Domain. У меня также есть доменная служба под названием UserService.
Давайте забудем о Dal, так как этот уровень не имеет значения для примера.
В моем Grpc< /code>, который будет идентично воспроизводиться как файлы .proto в моем проекте Contracts, я хочу использовать то же самое имя, что и у домена (или как можно ближе к нему). потому что мои клиенты будут использовать мой API, используя эти объекты, и я не хочу, чтобы они имели имена объектов внутри своего кода, такие как GrpcUser или UserContract или что-то еще.
Я хочу, чтобы они это сделали имеют простые имена классов без какой-либо информации, отражающей тот факт, что это классы Contracts.
Итак, в моем проекте Grpc у меня будет что-то вроде: User, Role, UserRequest, UserResponse, RoleRequest, RoleResponse, UserService, RoleService.
Некоторые из них имеют то же имя, что и мой домен сущности.
Но поскольку мой уровень Grpc никогда не будет напрямую взаимодействовать с моим слоем домена, у меня никогда не возникнет конфликта имен в этих проектах.
А теперь давайте поговорим об уровне приложения, где я бьюсь над соглашением об именах, которое хочу использовать.
По сути, это сервис из моего приложения. Слой иногда имеет имя, близкое к имени домена. Поэтому, если я хочу, чтобы логика была построена вокруг моей сущности User, мне понадобится UserService также на уровне моего приложения. Но у меня возникнет конфликт имен как с доменной версией UserService, так и с версией Grpc UserService.
Мне придется внедрить Domain.UserService в свой Application.UserService, а мой Application.UserService позже будет добавлен в мой Grpc.UserService, чтобы открыть мой Domain на внешний уровень Grpc.
Кроме того, мои службы Application должны иметь входные и выходные данные. Обычно они возвращают версию сущности Domain Dto, поэтому у меня нет проблем с созданием UserDto или более точных классов, таких как CreateUserDto.
Но для ввода обычно мне также нужны запросы. Точно так же, как мой проект Grpc.
Чтобы решить проблему с именованием, я начал добавлять Application ко всем моим классам в этом проекте. Например, у меня будет UserApplicationService, который будет получать CreateUserApplicationRequest и возвращать UserDto.
Но эти имена очень длинные и не удобен в использовании, и я никогда не видел, чтобы кто-нибудь использовал такое соглашение об именах (но, возможно, я ошибаюсь в этом вопросе.)
Поэтому мои вопросы: неправильный ли мой выбор именования ? Если нет, то как я могу назвать свои объекты и службы внутри уровня приложения?

Подробнее здесь: https://stackoverflow.com/questions/789 ... xternal-la