Comments 6
Крутая статья, спасибо вам!
Пример достаточно простой, но как быть если проект большой? :)
Т.е. в текущем примере у вас модуль Shop, но в реальных проектах модулей как минимум 10, а если мы говорим еще и про контексты внутри домена, то иерархия достаточно сложная. Как это всё должно выглядеть?
Подобную конфигурацию deptrac мы используем на большом монолите, основная сложность была в том что много мест не соответствовали архитектуре и мы часть файлов добавляли в ignore. И соответственно, сразу появляется техдолг на рефакторинг)
Файл игнора
parameters:
exclude_files:
# Массовые игноры папок
- '#.Core/Application.#'
И в основой файл настроек добавляем файл с игнорами
imports:
- deptrac.ignore.yaml
В случае если у нас в проекте есть изолированные модули, то можно просто использовать код из примера, в случае если в модуле еще есть изолированные контексты, можно это реализовать добавив дополнительный файл для проверки взаимодействия между контекстами. И в каждом модуле добавлять свою конфигурацию и подключать через imports в общий файл для удобства проверки. В целом даже если модулей/контекстов очень много, это не займет много времени, так как коллекторы +- унифицированные получаются
- name: ContextInModule
collectors:
- type: classLike
regex: ^Sberhealth\\Demo\\ModuleName\\ContextName\\.*
ruleset:
ContextInModule:
Спасибо, всё по делу
Чтобы не тащить доктрину в сущность можно вынести ее аннотации, например, в xml.
Применение статических анализаторов архитектуры на примере гексагональной архитектуры