Должен ли я делать инверсию зависимостей на том же уровне слоя
Предложение прямо в вашем вопросе намекает на то, почему это загадка:
Хранилище файлов — это общий поддомен, а учет — основной домен.
Похоже, существует неправильное представление о том, что представляет собой «программный уровень». Слои не определяются тем, где вы помещаете класс. Уровни программного обеспечения определяются тем, с чем в первую очередь связаны эти классы. Ответ на экзистенциальный вопрос «зачем я существую?» является основным мотиватором для группировки классов вместе в слое. Если существует группа классов для одной и той же основной цели, то они могут находиться на одном уровне[1].
На вашей диаграмме служба хранилища файлов правильно связана с уровнем инфраструктуры. Уровень инфраструктуры в первую очередь связан с взаимодействием со службами и ресурсами, неподконтрольными вашему приложению. Файловая система является прекрасным примером этого.
Бухгалтерская служба, которую вы описываете как «основной домен», в первую очередь связана с бизнес-логикой, а не с хранением файлов. Таким образом, служба учета не относится к уровню инфраструктуры. Служба учета принадлежит некоторому прикладному уровню. Бухгалтерская служба зависит от службы хранения файлов. Обычно эта зависимость представлена интерфейсом, позволяющим использовать моки при написании модульных тестов.
Имейте в виду, что Domain-Driven Design — это не архитектура приложения, а философия дизайна. DDD не указывает, куда должны идти классы File Storage Service и Accounting Service. Этот уровень детализации фиксируется в архитектуре приложения, такой как луковая архитектура, чистая архитектура и т. д. DDD помогает организовать бизнес-логику как средство управления сложностью. Один из способов добиться этого — удалить логику хранения данных из ваших основных бизнес-классов.
Многие архитектуры приложений имеют «инфраструктурный» уровень, потому что такое разделение желательно в целом, а не только для предметно-ориентированного проектирования. DDD не предписывает, куда именно должна идти бухгалтерская служба. Это обусловлено архитектурой приложения, а не какой-то философией проектирования бизнес-логики.
Ваш вопрос возникает из-за неправильной организации и группировки классов. Бухгалтерская служба, которая в первую очередь занимается бизнес-логикой и координацией, не относится к классу инфраструктуры. Бухгалтерская служба относится к другому уровню, который зависит от уровня инфраструктуры. Это решает ваш вопрос, потому что вам больше не нужна инверсия управления на одном уровне. Службы хранения файлов и учета находятся на разных уровнях.
Уровень, содержащий учетную службу, должен определять интерфейс для хранения файлов, который реализуется реальной службой хранения файлов на уровне инфраструктуры. Это следует принципу инверсии зависимостей («D» в «SOLID»). Зависимости между модулями должны основываться на абстракциях. Интерфейсы и абстрактные классы являются одними из наиболее распространенных абстракций, используемых на границах между модулями приложения.
- На техническом уровне классы часто группируются в слои на основе их зависимостей, но я бы сказал, что зависимости обнаруживаются после ответа на экзистенциальный вопрос: «Почему я существую?» Только после того, как выяснится, почему класс существует, вы сможете определить другие объекты, с которыми он должен взаимодействовать для выполнения своей основной цели в приложении, и, следовательно, к какому уровню он принадлежит.
Прикрепляю к посту несколько видео по теме: