Создание контекстов в структуре каталогов

Question

Я ищу обратную связь по определенной структуре каталогов для приложения. Я понимаю, что это не соответствует классическому формату переполнения стека, где есть такая вещь, как «правильный ответ», хотя думаю, что это интересно тем не менее. Чтобы дать значимую обратную связь, нужно сначала понять какой-то контекст, поэтому, пожалуйста, несите меня.

-

Два моих коллеги и я создал приложение, использующий Clean Architecture. HTTP-запросы на маршруты превращаются в модели запросов, которые передаются для использования в случаях, которые затем выплевывают модель ответа, которая передается ведущему.

Код полностью из открытого источника и находится в on GitHub. У нас также есть some docs, описывающие основные каталоги.

Мы думаем о реорганизации нашего кода и хотели бы получить обратную связь о том, что мы придумали до сих пор. В первую очередь среди причин для этой реорганизации являются:

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

• Приятно объединять сплоченные вещи вместе. Наш код пожертвования является сплоченным, и наш код приложения для членства является сплоченным, хотя оба они не зависят друг от друга. Это тесно связано с понятием ограниченных контекстов в доменном дизайне. Прямо сейчас эти контексты явно не видны в нашем коде, поэтому легко сделать их зависимыми друг от друга, особенно если вы не знакомы с доменом.

Это те контексты, которые мы определили до сих пор. Это предварительный список и просто дать вам идею, а не ту часть, на которую я хочу получить отзывы.

• Пожертвование
• Членство
• поддержка Форма материал (проверка электронной почты, поколение IBAN и т.д.)

Часть Я хочу обратную связь на это структура каталога мы думаем о переходе на:

src/ 
    Context_1/ 
     DataAccess/ 
     Domain/ 
      Model/ 
      Repositories/ 
     UseCases/ 
     Validation/ 
     Presentation/ 
     Authorization/ 
    Context_2/ 
    Factories/ 
    Infrastructure/ 

tests/ 
    Context_1/ 
     Unit/ 
     Integration/ 
     EdgeToEdge/ 
     System/ 
     TestDoubles/ 
    Context_2/ 

Папка Authorization/ непосредственно внутри контекста предоставит дом для наш в настоящее время странно размещенный код авторизации в инфраструктуре. Другой код, не являющийся частью нашего домена, но связанный с ним, может перейти непосредственно в контекстную папку и получить свою собственную папку, если между ними есть связная/связанная куча вещей, например авторизация.

Я рад предоставить дополнительную информацию, необходимую для предоставления полезной обратной связи.

Answer 1

Прямо сейчас у нас нет хорошего места для размещения вещей, которые не являются частью нашего домена, но каким-то образом привязаны к нему.

В настоящее время эти контексты явно не видны в нашем коде, поэтому их легко установить друг на друга, особенно если вы не знакомы с доменом.

Есть как технические, так и нетехнических способов решения этой проблемы:

• Вы можете обеспечить применение более строгих разделение с помощью библиотек классов. Более очевидно, что вы зависите от чего-то, если вам нужно импортировать dll/reference другой проект. Он также предотвратит круговые зависимости.
• Кодовые обзоры/дисциплина - нетехнический способ справиться с этим.

Я использовал Hexagonal Architecture с DDD, где домен находится посередине. Другие проблемы, такие как репозитории, представлены интерфейсами. Затем ваши адаптеры ссылаются на домен, но никогда в другом направлении. Таким образом, у вас может быть IRepository в вашем домене, но ваш WhateverDatabaseRepository находится в собственном проекте. Затем ответственность за использование сервисов/обработчиков приложений выполняет координация ваших вариантов использования и загрузка адаптеров. Это также означает, что вы будете применять сквозные проблемы, такие как авторизация.

Я бы порекомендовал вам посмотреть видеоролики Грега Юнга (попробуйте this one) и прочитайте Vaughn Vernon's IDDD, как он структурирует приложения и занимается такими вопросами, как ваша. (Жаль, что мой ответ в основном смотреть 6hr видео и читать 600+ страниц книги, но они оба действительно помогли прояснить некоторые более «мохнатый» аспекты DDD для меня)

В качестве примера см https://github.com/gregoryyoung/m-r/blob/master/SimpleCQRS/CommandHandlers.cs