А если развивать мысль дальше, то мы придем к тому, что микросервисная архитектура также является одной единцей развервертования и эта единица - информационная система.
Не стоит эту мысль развивать таким образом. Использование микросервисов неоправдано, если они спроектированы так, что развернуть их можно только все одновременно. Независимое развертывание - одно из преимуществ микросервисов, которое к тому же способствует независимой разработке. И один из важных аспектов проектирования является в управлении зависимостями между ними, чтобы минимизировать область влияния вносимых в один из микросервисов изменений.
Например CRM не может выполнять возложенные на нее функции без БД, сервера приложений, клиента для доступа к этой CRM и т.д.
Конечный пользователь действительно работает с системой как с единым целым. Но разрабатывать эту систему как единое целое просто невозможно, потому что все ее детали слишком сложно одновременно удержать в голове.
Об этом говорит Стив Макконел в книге Совершенный код. Он называет управление сложностью основным императивом(законом) разработки. Не погрязнуть в сложности нам помогает декомпозиция. Следуя принципу Separation of concerns нужно разделить одно большое сложное на более маленькие части, которые уже проще осознать и понять. Главное, чтобы эти части получились максимально независимыми(абсолютно независимыми сделать конечно не выйдет) иначе все равно придется "подгружать" в голову дополнительные знания о зависимостях.
Декомпозируя описанную вами систему, мы можем использовать клиент-серверную архитектуру, которая описывает зоны ответственности и правила взаимодействия каждой составляющей. Далее можно перейти на "сервер"(backend) и декомпозировать его дальше, применяя ту или иную архитектуру(n-tier, sliced, clean). Таким образом в идеале, решая конкретную задачу можно будет сосредоточиться на относительно небольшом участке системы.
Тогда в чем отличие модуля от микросервиса? В том, что работает либо все, либо ничего?
Развивая мысль управления сложностью и тот и другой служат одной цели - получение максимально самостоятельной части системы, над которой можно работать независимо. Просто микросервисы идут дальше модулей и выстраивают "физические" границы между собой, потому что работают в разных процессах.
Плюс к этому позволяют более гибко масштабировать как сами сервисы так и их разработку, быть толератным к отказу части системы. Но при этом добавляют операционных расходов на свое обслуживание и мониторинг.
Возможно нашел ответ на свой же вопрос. В статье Clarified CQRS Udi Dahan подчеркивает ключевую составляющую CQRS:
A core element of CQRS is rethinking the design of the user interface to enable us to capture our users’ intent such that making a customer preferred is a different unit of work for the user than indicating that the customer has moved or that they’ve gotten married.
Т.е. команды должны быть, что называется, fine-grained чтобы обеспечить масштабируемость и не потерять из-за ошибок параллелизма.
UseCase Якобсона как прародитель Interactor'a Мартина описывает как актор(человек или система) достигает цели с использованием нашего ПО. А это может включать в себя выполнение нескольких операций, что как раз может вызвать ошибки при паралелльном выполнении.
спасибо за отличную статью!
Интересует ваше мнение на следующий вопрос. В Clean architecture Роберта Мартин одним из основных элементов является класс Interactor, идею которого он позаимствовал у Якобсона. Согласно Мартину Interactor — это класс, содержащий верхнеуровневую логику приложения и реализующий конкретный пользовательский сценарий.
На первый взгляд от хэндлеров мы можем получить те же преимущества, что и от interactor: разделение на vertical slices и приблизиться к «кричащей архитектуре», когда просматривая команды и хэндлеры будет явно понятен способ взаимодействия с приложением.
Есть ли на ваш взгляд принципиальная разница между Interactor и Handler? И как мы должны реализовать Handler, чтобы получить все преимущества идеи, заключенной в Interactor?
Я так понимаю под «башней абстракций» вы подразумеваете тактические паттерны DDD. Как вы считаете для какой цели они были созданы и когда, на ваш взгляд, их применение действительно оправдано?
Видимо поэтому Вернон в Красной книге и начинает со стратегических паттернов.
Но на мой взгляд не стоит недооценивать и сложность создания UL и BC. Я думаю UL — это нечто гораздо большее чем «минимального взаимодействия с клиентом или ЦА своего продукта»(хотя это уже лучше, чем ничего), а грамотное выделение автономных BC — это вообще отдельная наука.
Ну если речь идет про конкретные практики, то они тоже есть, только до парного программирования не дошли и, положа руку на сердце, не test driven, а максимум test first пока что))
Конечно аналогия не покрывает все возможные сценарии. Думаю основная идея в том, что как в доме, так и в коде не нужно страдать из-за его неидеальности, потому что он не соответствует образцовым фото в журналах и описаниям паттернов в книгах. Основная цель — сделать дом/код комфортным для проживания/работы в нем. Чтобы поддерживать и расширять функционал можно было оперативно и удобно для всех участников команды.
Я также не знаком с реалиями строительства. Но я понял основную идею не столько как желание доказать, что аналогия со строительством на 100% неверна, сколько найти более точную модель для сегодняшних реалий. Более того, акцент смещен с технической составляющей разработки на командную работу и коммуникации. С этой точки зрения сравнение разработки с дизайном интерьера, а командной работы в общей кодовой базе как проживание в одной квартире кажется мне очень точной аналогией, помогающей понять как вести себя в пограничных ситуациях.
Спасибо за новую книгу в списке «к прочтению»! Сам всегда интересовался вопросами эффективного обучения и запоминания, и несколько книг из этой области описал в статье.
Интересный вариант :) ну а если серьезно, то, на мой взгляд, использование сленга это дискуссионный вопрос и применять его, безусловно, нужно дозировано. А крайние варианты, вроде «спаблишенный аппликейшн» и «опубликованное приложение» выглядят зачастую одинаково невнятно.
Спасибо за ваш комментарий, который побудил разобраться подробнее в этом вопросе. Несмотря на проблемы Docker Inc cам проект, думаю, рановато хоронить.
1. Проект Docker является OpenSource и, вероятно, найдет поддержку даже в случае отсутствия таковой от Docker Inc. Тем более вы сами упомянули о повсеместном использовании проекта.
2. Структура Docker-образов и исполняемая среда контейнеров поддерживает OCI, а значит одинакова для всех проектов, поддерживающих данный стандарт.
3. У меня нет практического опыта перевода приложения, работающего под управлением Kubernates, с Docker на другую среду запуска контейнеров, но, например, инструкция по переходу с Docker на CRI-O занимает буквально одну страницу.
Я допустил ошибку, инструкция должна выглядеть следующим образом: COPY --from=publish /publish .
Она говорит: «Скопируй со стадии publish содержимое папки /publish в текущую рабочую директорию (в данном случае это /app)»
Спасибо за комментарий!
Я описал те методы, которые вынес из прочтения данных книг и теперь я использую сам. Я не призываю читать именно эти книги и использовать именно описанные методы. Я предлагаю задуматься как изучать базовые теоретические вопросы таким образом, чтобы они сохранялись в памяти надолго, даже если к ним обращаются не очень часто.
Например, однажды я решил прочесть творение Рихтера. Думаю, никто не будет спорить о том, что такие разделы как работа очереди на финализацию, сборщика мусора, назначение доменов приложений обязательны к прочтению для всех кто считает себя .NET разработчиком, но не так уж часто возникает необходимость обратиться к ним на практике. Я особенно оценил полезность описанных выше методов как раз для таких разделов. При прочтении я делал так, как описал в статье(кроме скорочтения): читал по 45-60 мин утром и вечером. После чтения по дороге домой или, занимаясь домашними делами, я обдумывал то, что прочитал, рассматривал информацию с разных точек зрения, размышлял как это можно применить на практике, почему выбрана та или иная реализация, придумывал аналогии из жизни для описанной структуры/процесса/системы. Также спрашивал у опытных коллег приходилось ли им и в какаких случаях использовать то, о чем сегодня прочел. Когда по итогам прочитанного обращался также к статьям и блогам для углубления, то впоследствии делал заметки. Такой подход к чтению конечно требует бОльшего времени, но я верю, что он приносит плоды в виде качественного запоминания.
Соглашусь, что наличие знаний и умение их использовать — это не одно и то же. Но я уверен, что успешность использования имеющихся знаний зависит от нас самих. Думаю, что при возникновении практической задачи/проблемы нужно в первую очередь покопаться в памяти, а что же ты сам знаешь об этом вопросе, а уж потом, если нужно, спрашивать совета и искать решение в сети. Это поможет выработать определенный навык работы со своими же знаниями.
Не стоит эту мысль развивать таким образом. Использование микросервисов неоправдано, если они спроектированы так, что развернуть их можно только все одновременно. Независимое развертывание - одно из преимуществ микросервисов, которое к тому же способствует независимой разработке. И один из важных аспектов проектирования является в управлении зависимостями между ними, чтобы минимизировать область влияния вносимых в один из микросервисов изменений.
Конечный пользователь действительно работает с системой как с единым целым. Но разрабатывать эту систему как единое целое просто невозможно, потому что все ее детали слишком сложно одновременно удержать в голове.
Об этом говорит Стив Макконел в книге Совершенный код. Он называет управление сложностью основным императивом(законом) разработки. Не погрязнуть в сложности нам помогает декомпозиция. Следуя принципу Separation of concerns нужно разделить одно большое сложное на более маленькие части, которые уже проще осознать и понять. Главное, чтобы эти части получились максимально независимыми(абсолютно независимыми сделать конечно не выйдет) иначе все равно придется "подгружать" в голову дополнительные знания о зависимостях.
Декомпозируя описанную вами систему, мы можем использовать клиент-серверную архитектуру, которая описывает зоны ответственности и правила взаимодействия каждой составляющей. Далее можно перейти на "сервер"(backend) и декомпозировать его дальше, применяя ту или иную архитектуру(n-tier, sliced, clean). Таким образом в идеале, решая конкретную задачу можно будет сосредоточиться на относительно небольшом участке системы.
Развивая мысль управления сложностью и тот и другой служат одной цели - получение максимально самостоятельной части системы, над которой можно работать независимо. Просто микросервисы идут дальше модулей и выстраивают "физические" границы между собой, потому что работают в разных процессах.
Плюс к этому позволяют более гибко масштабировать как сами сервисы так и их разработку, быть толератным к отказу части системы. Но при этом добавляют операционных расходов на свое обслуживание и мониторинг.
Т.е. команды должны быть, что называется, fine-grained чтобы обеспечить масштабируемость и не потерять из-за ошибок параллелизма.
UseCase Якобсона как прародитель Interactor'a Мартина описывает как актор(человек или система) достигает цели с использованием нашего ПО. А это может включать в себя выполнение нескольких операций, что как раз может вызвать ошибки при паралелльном выполнении.
Интересует ваше мнение на следующий вопрос. В Clean architecture Роберта Мартин одним из основных элементов является класс Interactor, идею которого он позаимствовал у Якобсона. Согласно Мартину Interactor — это класс, содержащий верхнеуровневую логику приложения и реализующий конкретный пользовательский сценарий.
На первый взгляд от хэндлеров мы можем получить те же преимущества, что и от interactor: разделение на vertical slices и приблизиться к «кричащей архитектуре», когда просматривая команды и хэндлеры будет явно понятен способ взаимодействия с приложением.
Есть ли на ваш взгляд принципиальная разница между Interactor и Handler? И как мы должны реализовать Handler, чтобы получить все преимущества идеи, заключенной в Interactor?
Но на мой взгляд не стоит недооценивать и сложность создания UL и BC. Я думаю UL — это нечто гораздо большее чем «минимального взаимодействия с клиентом или ЦА своего продукта»(хотя это уже лучше, чем ничего), а грамотное выделение автономных BC — это вообще отдельная наука.
Интересный вариант :) ну а если серьезно, то, на мой взгляд, использование сленга это дискуссионный вопрос и применять его, безусловно, нужно дозировано. А крайние варианты, вроде «спаблишенный аппликейшн» и «опубликованное приложение» выглядят зачастую одинаково невнятно.
1. Проект Docker является OpenSource и, вероятно, найдет поддержку даже в случае отсутствия таковой от Docker Inc. Тем более вы сами упомянули о повсеместном использовании проекта.
2. Структура Docker-образов и исполняемая среда контейнеров поддерживает OCI, а значит одинакова для всех проектов, поддерживающих данный стандарт.
3. У меня нет практического опыта перевода приложения, работающего под управлением Kubernates, с Docker на другую среду запуска контейнеров, но, например,
инструкция по переходу с Docker на CRI-O занимает буквально одну страницу.
COPY --from=publish /publish .Она говорит: «Скопируй со стадии publish содержимое папки /publish в текущую рабочую директорию (в данном случае это /app)»
Спасибо за комментарий!
А я и не спорю, только попытался ответить на вопрос: как учить так, чтобы потом вспомнить всё (ну или хотя бы большую часть) из того, что изучил
Например, однажды я решил прочесть творение Рихтера. Думаю, никто не будет спорить о том, что такие разделы как работа очереди на финализацию, сборщика мусора, назначение доменов приложений обязательны к прочтению для всех кто считает себя .NET разработчиком, но не так уж часто возникает необходимость обратиться к ним на практике. Я особенно оценил полезность описанных выше методов как раз для таких разделов. При прочтении я делал так, как описал в статье(кроме скорочтения): читал по 45-60 мин утром и вечером. После чтения по дороге домой или, занимаясь домашними делами, я обдумывал то, что прочитал, рассматривал информацию с разных точек зрения, размышлял как это можно применить на практике, почему выбрана та или иная реализация, придумывал аналогии из жизни для описанной структуры/процесса/системы. Также спрашивал у опытных коллег приходилось ли им и в какаких случаях использовать то, о чем сегодня прочел. Когда по итогам прочитанного обращался также к статьям и блогам для углубления, то впоследствии делал заметки. Такой подход к чтению конечно требует бОльшего времени, но я верю, что он приносит плоды в виде качественного запоминания.