Комментарии 12
1. На мой взгляд у вас не учтено, кто будет ставить задачи с точки зрения бизнеса и как эти люди между собой общаются. См. закон Конвея — «Организации проектируют системы, которые копируют структуру коммуникаций в этой организации». Откуда часто вытекает паттерн BoundedContext
2. Глобальная или локальная область применения — опасная история. Правильно сделать глобальную фичу — это серьезные затраты. А неправильно — создать большой риск проблем развития в дальнейшем (вот прямо сейчас работаю над проектом, где был сделан глобальный сервис для хранения настроек всех сервисов, это повлекло очень много проблем, неочевидных в момент выбора такого решения). Поэтому часто бывает так, что фича может по смыслу и глобальная, но экономически нецелесообразно делать её таковой.
2. Глобальная или локальная область применения — опасная история. Правильно сделать глобальную фичу — это серьезные затраты. А неправильно — создать большой риск проблем развития в дальнейшем (вот прямо сейчас работаю над проектом, где был сделан глобальный сервис для хранения настроек всех сервисов, это повлекло очень много проблем, неочевидных в момент выбора такого решения). Поэтому часто бывает так, что фича может по смыслу и глобальная, но экономически нецелесообразно делать её таковой.
я бы хотел подчеркнуть, что суть того, что описано в статье, не сильно должны влиять на сами дизайн-решения. Какое бы решение Вы не приняли и кто бы не ставил задачу — так или иначе у вас появится код. А предложенная классификация позволяет этот код более организованно хранить и самой структурой дополнительно отражать замысел его создателя. Если в конкретном проекте некую фичу нецелесообразно делать как чисто глобальную, соответственно Вы и думаете про нее как про «проектную» или «смежную» и позиционируете так. А засчет соглашения и другие участники команды четко знают, как про нее стоит «думать».
да, кстати, я предположу из примера пункта 2, что Вы ведете речь не совсем про глобальный слой кода в терминах статьи, а про переиспользование приложения (технического), коим является Ваш сервис настроек. Т.е. это вопрос о построении систем связанных приложений и он существенно шире и сложнее, чем вопрос организации кода для одного приложения. В статье никак не рассмотрены вопросы организации эффективных систем из приложений (сервисов). Грубо говоря, не описано, как решать, что лучше: «посчитать» в самом приложении или получать через «входы» по запросу как готовый результат.
Вероятно тогда стоит обозначить, что вы понимаете под термином «приложение», а что «проект». Потому что в нашем случае это всё одно большое приложение, состоящее из разных микросервисов и фронтовых модулей.
Я понимаю под этим «единицу развертывания». Eдиницы, с которыми непосредственно взаимодействуют люди, я называю «приложения», а те, с которыми не люди — сервисами. Похоже, что приложение в Вашем случае — это сумма «моих» приложений (фронтовых модулей). Ну а проект — это набор таких единиц, который решает задачу.
На самом деле разница не очень большая. Ну вот взяли бы мы этот переиспользуемый код в виде большой библиотеки, а не сервиса, то мы бы поймали как минимум половину от всех имеющихся сейчас проблем.
Мне нравится как написана статья, хорошая последовательность изложения мыслей, хороший понятный язык.
В целом это действительно описание велосипеда одного конкретного архитектурного стиля, НО хорошее описание велосипеда!
Одно замечание с моей стороны, универсальности архитектуры можно достигнуть, если мы говорим о наборе однотипных проектов, иначе об универсальности речи идти не может.
Техническим .Tech я называю тот код, который используются в продакшн, но прим это напрямую не связан с назначением приложения. Логирование, телеметрия, описание каких-то своих внутренних протоколов
.Infrastructure
.Calc В слово “вычисление” я вкладываю максимально широкий смысл,тогда уж .Logic
Не знаю на каком языке программирования вы пишете, но я бы с большим интересом взглянул на пример ToDo сделанным по вашей архитектуре.
В принципе, мы можете переназвать на свой вкус все специальные слова и это ничего не изменит. Причина, почему у меня .Tech, а не .Infrastructure — моя любовь использовать максимально возможные короткие имена.
Не могу согласиться про .Logic вместо .Calc так как термин логика уже «задействован» для описание слоев — логика приложения и логика бизнеса и будет вызывать путаницу. Имхо, хорошей альтернативой .Calc еще было было бы .Alg — Algorithms.
Про пример — не возьмусь обещать пока. Как оказалось, написать статью намного сложнее, чем мне думалось все это время: )
Не могу согласиться про .Logic вместо .Calc так как термин логика уже «задействован» для описание слоев — логика приложения и логика бизнеса и будет вызывать путаницу. Имхо, хорошей альтернативой .Calc еще было было бы .Alg — Algorithms.
Про пример — не возьмусь обещать пока. Как оказалось, написать статью намного сложнее, чем мне думалось все это время: )
Жару тут еще поддает заказчик, формулируя требования в форме «я хочу получить уведомление, когда наши клиенты оформляют такую-то заявку на этой странице сайта», когда на самом деле деле он имеет ввиду просто «оформляя заявку», имея в виду и мобильное приложение, где это возможно сделать и ссылку в каком-нибудь промо письме.
Нет ничего хуже для заказчика чем программист, который делает именно то что просит заказчик… в лоб. Пару раз так сделать, глядишь и поймёт что нужны специально обученные люди для фильтрации потоков мыслей и постановки задач… аналитики..)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Универсальная архитектура приложений