Архитектура приложения и организация кода
В своей записи я собрал некоторые материалы по архитектуре Clean, она замечательна, но теперь вопрос в реализации. Я видел несколько способов организации дерева исходного кода: все в кучу, по возможностям, по слоям.
Но что-то меня это не совсем устраивало, и в поисках я вышел на организацию по компонентам.
Пытаясь понять архитектуру Clean я искал для себя модель в реальном мире, которая бы могла эти принципы хоть частично показать. Организация кода по компонентам оказалась именно тем ключом, который подошел.
Как структурировать исходный код?
Первое на что я наткнулся Coding: Packaging by vertical slice — тут человек пишет как он пришел к компонентной организации кода. И главное ему тогда ответил и сам автор Clean-архитектуры Uncl Bob дав пояснения: "Все классно, но я еще разделяю Controller на две части, сам Controller и interactor, Interactor знает как принять данные от Controller и отработать с сущностями домена, репозиториями.
Тут автор предложил такую структуру:
project- location
- Address
- Location
- LocationController
- LocationRepository
- LocationService
- platform
- StringUtils
- price
- Cost
- CostFactory
- Distance
- Price
- PriceController
- PriceRepository
По совету Uncle Bob сюда бы добавились Interactor-ы:
project
- location
- Address
- Location
- LocationController
- LocationInteractor
- LocationRepository
- LocationService
- platform
- StringUtils
- price
- Cost
- CostFactory
- Distance
- Price
- PriceController
- PriceInteractor
- PriceRepository
Такая структура показывает все детали в одном месте, не нужно лазить по куче папок, чтобы понять где еще чего надо поменять. Да слоев архитектуры тут не видно сразу, но код должен нам показывать, то чем оно занят как можно яснее - это решение именно предлагает ясность.
Ясность и простоту в изменении кода отмечает и разработчик Pannonian Coder в своей записи Packages and separation of concerns от 2014.г. Странно, говорит, сначало было класть файлы html рядом с контроллерами, но потом оказалось удобно, что не надо куда-то прыгать - все рядом.
Еще пример перепаковки исходгого кода в компоненты от в статье "An architecturally-evident coding style".
Отсюда я почерпнул - слои это детали реализации, слоит теперь не на первом уровне деления, а внутри компонентов.
Simon Brown в своей статье Package by Component and Architecturally-aligned Testing приводит разные варианты организации кода с иллюстрациями и приходит к компонентной. От предлагает прятать реализацию за интерфейсом комонента (не делать публичными классы за пределами пакета компонента, говоря о Java), и задается вопросом о тестировании компонента и возможности иммитации внутренних его частей в модульном тестировании, когда детали реализации не публичны.
Пример на коде в IDE от Simon Brown.
Пример для Java на github от Simon Bown https://github.com/techtribesje/techtribesje/tree/master/techtribes-core/src/je/techtribes/component
@UncleBob тоже описывает данный подход в своей книге "A Craftsman's Guide to Software Structure and Design" в разделе PACKAGE BY COMPONENT и показывает на схеме отличие разных подходов в организации кода в разделе ORGANIZATION VERSUS ENCAPSULATION.
Двигаясь далее я нашел и прочел запись Component-based Software Development, тут автор проводит аналогию с производством автомобилей, показывая как копонентная организация успешно позволяет конструировать решения в других сферах — и именно этот пример позволил создать мне единую картину как применить архитектуру Clean на практике.
Связанные вопросы
Случайно наткнулся на вопрос: а хорошо ли хранить интерфейсы в отдельном пакете?
Ответ был: нет, обычно это плохая практика, может быть кроме случая когда у вас слишком много интерфейсов.
Согласен, это размывает код, делая структуру чрезмерно детальной.
А как же модульное тестирование, если все скрыто за интерфесом компонента? А всегда ли нужно модульное тестироватие? Здесь @simonbrown отвечает что не надо беспокоиться пока оно реально вам не понадобиться. Но я для себя еще не решил, оставлю вопрос открытым...
