Публикую серию гостевых постов от @YinKio:
Гибкая архитектура. Взглаяд через призму ответственности
Ряд кратких постов о построении гибкой архитектуры с точки зрения распределения ответственности.
- Критерии
- Принципы
- Инструменты
Ознакомление с ними может повысить вероятность сохранения гибкости архитектуры на длительном промежутке времени.
Гибкая архитектура. Взглаяд через призму ответственности
Ряд кратких постов о построении гибкой архитектуры с точки зрения распределения ответственности.
- Критерии
- Принципы
- Инструменты
Ознакомление с ними может повысить вероятность сохранения гибкости архитектуры на длительном промежутке времени.
👍11
Критерии гибкости архитектуры
Гибкая архитектура - это архитектура, способная эффективно адаптироваться к изменяющимся требованиям масштабируемости, функциональности и безопасности системы; это архитектура, которую удобно использовать.
Построение гибкой архитектуры невозможно без понимания критериев, согласно которым её можно назвать гибкой.
Самый важный критерий - это результат. Результатом качественной архитектуры является высокая скорость внесения изменений в работу приложения.
Остальные критерии являются косвенными. Это значит, что соблюдение каждого из них увеличивает вероятность сохранения максимальной скорости внесения изменений в продукт, однако не гарантирует её высокие показатели.
Важность косвенного критерия зависит от состояния текущего проекта. Выбирать, какой из них имеет наибольший приоритет, нужно исходя из тактических и стратегических преимуществ, которые они принесут в случае их успешного соблюдения. Выработка чёткой стратегии оценки важности критериев, а также методы их измерения - тема очень интересная, однако выходит за рамки этого ряда постов.
В зависимости от автора косвенные критерии могут очень сильно отличаться друг от друга. Ниже я привожу краткий и далеко не полный список важных критериев.
Перечень косвенных критериев
- Ясность и читаемость кода - чем выше, тем лучше.
- Распределение ответственности между компонентами
- Покрытие юнит тестами - средний оптимальный показатель 80%
- Степень связанности кода (coupling) - чем ниже, тем лучше
- Скорость рефакторинга
- Скорость тестирования
Понимание критериев и умение расставлять приоритеты на основании состояния текущего проекта может помочь в построении гибкой архитектуры. Однако от них мало пользы, если не знать принципы и инструменты построения архитектуры.
Гибкая архитектура - это архитектура, способная эффективно адаптироваться к изменяющимся требованиям масштабируемости, функциональности и безопасности системы; это архитектура, которую удобно использовать.
Построение гибкой архитектуры невозможно без понимания критериев, согласно которым её можно назвать гибкой.
Самый важный критерий - это результат. Результатом качественной архитектуры является высокая скорость внесения изменений в работу приложения.
Остальные критерии являются косвенными. Это значит, что соблюдение каждого из них увеличивает вероятность сохранения максимальной скорости внесения изменений в продукт, однако не гарантирует её высокие показатели.
Важность косвенного критерия зависит от состояния текущего проекта. Выбирать, какой из них имеет наибольший приоритет, нужно исходя из тактических и стратегических преимуществ, которые они принесут в случае их успешного соблюдения. Выработка чёткой стратегии оценки важности критериев, а также методы их измерения - тема очень интересная, однако выходит за рамки этого ряда постов.
В зависимости от автора косвенные критерии могут очень сильно отличаться друг от друга. Ниже я привожу краткий и далеко не полный список важных критериев.
Перечень косвенных критериев
- Ясность и читаемость кода - чем выше, тем лучше.
- Распределение ответственности между компонентами
- Покрытие юнит тестами - средний оптимальный показатель 80%
- Степень связанности кода (coupling) - чем ниже, тем лучше
- Скорость рефакторинга
- Скорость тестирования
Понимание критериев и умение расставлять приоритеты на основании состояния текущего проекта может помочь в построении гибкой архитектуры. Однако от них мало пользы, если не знать принципы и инструменты построения архитектуры.
👍29
Принципы проектирования архитектуры
Одним из важных аспектов для построения гибкой архитектуры является распределение ответственности между компонентами системы. В основании предложенных принципов лежит работа с ответственностью, потому что именно с ней мы работаем в коде, распределяя обязанности и задачи между компонентами.
Здесь рассмотрены проблемы некоторых популярных принципов и предложена им альтернатива.
Следует отметить, что данный набор принципов, как и все другие, бесполезен, если не понимать, каким критериям должна соответствовать гибкая архитектура, а также без понимания, какие инструменты управления ответственностью существуют.
Проблемы SOLID
SOLID принципы также предназначены для построения гибкой архитектуры ПО. Однако они обладают рядом недостатков:
- Неочевидность терминов, используемых в расшифровке
- Малое внимание к ответственности компонентов, из-за чего открывается большой простор для спекуляций
- Сложные формулировки
- Прямая ориентация на ООП, на ФП есть только неявная
- Отсуствие балансирующих принципов
Проблемы DRY, KISS, YAGNI
Данные принципы прекрасны в своей простоте. Они ориентированы на определения областей ответственности, однако это не указано в их расшифровке.
Переработанный перечень принципов
Некоторые из предложенных принципов являются переработкой уже существующих в контексте распределения ответственности. Их цель - обеспечить не меньшую полноту по сравнению с предшественниками и решить их проблемы. Здесь они представлены в тезисном виде.
Важные определения
Ответственность здесь представляется обязанностями и задачами, которые должен выполнять компонент.
Делегирование - передача части ответственности другому компоненту
Вмешательство - неуместное участие в процессе выполнения задачи, создание помех, которые уменьшают понятность кода для программиста.
Определение области ответственности - это интерфейс, определение класса, функции, или части тела функции.
Перечень принципов
Essence Defines Responsibility
Компоненты, ближе к сути предметной области, определяют область ответственности компонентов, которые дальше от неё
No Duplicate Responsibility Principle
Дублирование определений области ответственности компонентов должно устраняться
Delegate Responsibility Principle
Компонент должен делегировать часть ответственности, если это упростит использование системы
Reversive Delegate Responsibility Principle
Компонент должен возвращать часть или полностью отказываться от ответственности, если это упростит использование системы
Isolate Responsibility Principle
Компонент не должен допускать вмешательства в свою область ответственности, а также сам не должен вмешиваться в область ответственности другого компонента
Assign Necessary Orders Principle
Компонент должен поручать только те обязанности и задачи, которые необходимы для его работы
Complete All Orders Principle
Компонент должен выполнять все обязанности в своей области ответственности
Complete Necessary Orders Principle
Компонент должен брать на себя только те обязанности и задачи, которые ему поручили
Итог
Использование данного набора принципов увеличит вероятность удобного распределения ответственности. Однако слепое их применение вредно. Критерии и инструменты могут помочь не забыть о назначении этих принципов.
Одним из важных аспектов для построения гибкой архитектуры является распределение ответственности между компонентами системы. В основании предложенных принципов лежит работа с ответственностью, потому что именно с ней мы работаем в коде, распределяя обязанности и задачи между компонентами.
Здесь рассмотрены проблемы некоторых популярных принципов и предложена им альтернатива.
Следует отметить, что данный набор принципов, как и все другие, бесполезен, если не понимать, каким критериям должна соответствовать гибкая архитектура, а также без понимания, какие инструменты управления ответственностью существуют.
Проблемы SOLID
SOLID принципы также предназначены для построения гибкой архитектуры ПО. Однако они обладают рядом недостатков:
- Неочевидность терминов, используемых в расшифровке
- Малое внимание к ответственности компонентов, из-за чего открывается большой простор для спекуляций
- Сложные формулировки
- Прямая ориентация на ООП, на ФП есть только неявная
- Отсуствие балансирующих принципов
Проблемы DRY, KISS, YAGNI
Данные принципы прекрасны в своей простоте. Они ориентированы на определения областей ответственности, однако это не указано в их расшифровке.
Переработанный перечень принципов
Некоторые из предложенных принципов являются переработкой уже существующих в контексте распределения ответственности. Их цель - обеспечить не меньшую полноту по сравнению с предшественниками и решить их проблемы. Здесь они представлены в тезисном виде.
Важные определения
Ответственность здесь представляется обязанностями и задачами, которые должен выполнять компонент.
Делегирование - передача части ответственности другому компоненту
Вмешательство - неуместное участие в процессе выполнения задачи, создание помех, которые уменьшают понятность кода для программиста.
Определение области ответственности - это интерфейс, определение класса, функции, или части тела функции.
Перечень принципов
Essence Defines Responsibility
Компоненты, ближе к сути предметной области, определяют область ответственности компонентов, которые дальше от неё
No Duplicate Responsibility Principle
Дублирование определений области ответственности компонентов должно устраняться
Delegate Responsibility Principle
Компонент должен делегировать часть ответственности, если это упростит использование системы
Reversive Delegate Responsibility Principle
Компонент должен возвращать часть или полностью отказываться от ответственности, если это упростит использование системы
Isolate Responsibility Principle
Компонент не должен допускать вмешательства в свою область ответственности, а также сам не должен вмешиваться в область ответственности другого компонента
Assign Necessary Orders Principle
Компонент должен поручать только те обязанности и задачи, которые необходимы для его работы
Complete All Orders Principle
Компонент должен выполнять все обязанности в своей области ответственности
Complete Necessary Orders Principle
Компонент должен брать на себя только те обязанности и задачи, которые ему поручили
Итог
Использование данного набора принципов увеличит вероятность удобного распределения ответственности. Однако слепое их применение вредно. Критерии и инструменты могут помочь не забыть о назначении этих принципов.
👍48🔥8
Инструменты определения ответственности
Для того, чтобы эффективно применять инструменты для определения ответственности, нужно знать область, в которой ответственность распределяется, время а также между кем она распределяется.
Областью в данном случае представляется структура компонентов в системе, начало и конец ответственности определяются условными временными рамками, распределяется же ответственность между компонентами системы. Ответственность здесь - это задача компонента или его перечень обязанностей. Компонент - объект или функция.
В программировании есть два основных инструмента для определения ответственности компонентов: интерфейс и функция. Интерфейс предназначен для разграничения ответственности в рамках структуры системы, функция - во временных рамках.
Распределение ответственности в рамках структуры системы представляется группировкой методов или функций. Во временных - это их вызов и получение результата или побочного эффекта.
В ООП ответственность распределяется между объектами и методами с помощью определений классов или интерфейсов. В ФП - между функциями. Хотя в ФП явно не выделяют понятие "интерфейс", тем не менее он наблюдается при группировке функций по типу, с которыми они работают.
Таким образом, не зависимо от ООП или ФП в программировании есть два основных инструмента для определения ответственности: интерфейс и функция.
Понимание, какими инструментами орудует программист, увеличивает ваероятность их уместного применения. В этом также могут помочь критерии гибкой архитектуры и принципы её построения
Для того, чтобы эффективно применять инструменты для определения ответственности, нужно знать область, в которой ответственность распределяется, время а также между кем она распределяется.
Областью в данном случае представляется структура компонентов в системе, начало и конец ответственности определяются условными временными рамками, распределяется же ответственность между компонентами системы. Ответственность здесь - это задача компонента или его перечень обязанностей. Компонент - объект или функция.
В программировании есть два основных инструмента для определения ответственности компонентов: интерфейс и функция. Интерфейс предназначен для разграничения ответственности в рамках структуры системы, функция - во временных рамках.
Распределение ответственности в рамках структуры системы представляется группировкой методов или функций. Во временных - это их вызов и получение результата или побочного эффекта.
В ООП ответственность распределяется между объектами и методами с помощью определений классов или интерфейсов. В ФП - между функциями. Хотя в ФП явно не выделяют понятие "интерфейс", тем не менее он наблюдается при группировке функций по типу, с которыми они работают.
Таким образом, не зависимо от ООП или ФП в программировании есть два основных инструмента для определения ответственности: интерфейс и функция.
Понимание, какими инструментами орудует программист, увеличивает ваероятность их уместного применения. В этом также могут помочь критерии гибкой архитектуры и принципы её построения
👍30
Ребята, последнее время очень много хейта вокруг, и сейчас сильно хейтят Владилена Минина, он снял подробный разбор проблемы, я просто хочу выразить ему поддержку и несмотря на то, что у нас были разногласия, пожелать найти выход из ситуации. Я уверен, что он есть.
Telegram
Владилен Минин
Он вам не АйтиБорода (8/11)
Не простой для меня ролик. Конфликты, недопонимания, лицемерие, политика - все эти темы пришлось пропустить через себя за последние 3 года при подготовке видео
Да-да, видео намного шире, чем вам может показаться. Моя задача …
Не простой для меня ролик. Конфликты, недопонимания, лицемерие, политика - все эти темы пришлось пропустить через себя за последние 3 года при подготовке видео
Да-да, видео намного шире, чем вам может показаться. Моя задача …
👍72🤡43🔥7💩4💯4❤2🤔2🥴2👎1😁1🌚1
Про информативность диаграмм и схем
Одна из ошибок проектирования - чрезмерное увлечение абстракциями. Смысл проектирования заключается не в том, чтобы сказать "я художник я так вижу", а в том, чтобы понять каким образом будет реализована будущая программа или автоматизированная система до ее фактической реализации.
Естественно, что в рамках проектирования не имеет смысла рассматривать все детали будущего кода, а нужно сосредоточиться на основных моментах, которые важны для реализации.
Обычно достаточно уточнять схему до момента когда можно по схеме определить семантику (смысловое значение) элементов указанных на схеме.
Давайте разберемся на примере. Как можно выразить семантику диаграммы под пунктом А на рисунке выше? Можно сказать, что это просто "класса А это генерализация класса Б". Но на инженерном языке это будет звучать как-то так "что-то является чем-то". Весьма размытая семантика и пример чрезмерной абстракции на диаграмме.
С другой стороны под пунктом Б в схему добавлен нужный смысл и уже можно прочитать, что "Машина является автобусом" или "Автобус - генерализация машины".
Второй пример явно более удачный с позиции семантики, так как появляется не только "смысл", но и коллизия, ведь данное решение на практике будет приносить много "боли" и его следует пересмотреть.
Вторая диаграмма позволяет выявить проблему до начала работ над кодом - это и есть польза проектирования.
Однако, бывают случаи, когда архитектор неправильно воспринимает семантику схемы и в результате в работу уходит проект, который не может быть реализован на практике. Но это уже другая история.
Нам же важно понять, что хорошая схема должна быть настолько информативной, чтобы ответить на следующие вопросы:
- назначение элементов на схеме (и связанные с ними ограничения);
- взаимосвязь (влияние) элементов друг на друга;
- может ли элемент быть исключен из схемы и какие последствия это будет иметь;
- может ли элемент быть заменен и какие последствия это будет иметь;
- можно ли на основе схемы построить истинные утверждения, а не просто сформулировать абстрактные догадки.
UPD. Примеры в данном случае оба показывают неудачные кейсы, первый пример показывает "отсутствие смысла", а второй имеет смысл, но при этом нарушена логика, так как наследовать машину от автобуса - неверно. Как раз наличие во втором примере семантики, позволяет нам увидить ошибку на этапе проектирования.
Реакции влияют на темы постов:
100 x 💡 - пост по архитектуре
100 х 🥷 - пост про код
100 х 👑 - пост про профессиональный рост
#знания #проектирование
SOER | PRO | Boosty
Одна из ошибок проектирования - чрезмерное увлечение абстракциями. Смысл проектирования заключается не в том, чтобы сказать "я художник я так вижу", а в том, чтобы понять каким образом будет реализована будущая программа или автоматизированная система до ее фактической реализации.
Естественно, что в рамках проектирования не имеет смысла рассматривать все детали будущего кода, а нужно сосредоточиться на основных моментах, которые важны для реализации.
Обычно достаточно уточнять схему до момента когда можно по схеме определить семантику (смысловое значение) элементов указанных на схеме.
Давайте разберемся на примере. Как можно выразить семантику диаграммы под пунктом А на рисунке выше? Можно сказать, что это просто "класса А это генерализация класса Б". Но на инженерном языке это будет звучать как-то так "что-то является чем-то". Весьма размытая семантика и пример чрезмерной абстракции на диаграмме.
С другой стороны под пунктом Б в схему добавлен нужный смысл и уже можно прочитать, что "Машина является автобусом" или "Автобус - генерализация машины".
Второй пример явно более удачный с позиции семантики, так как появляется не только "смысл", но и коллизия, ведь данное решение на практике будет приносить много "боли" и его следует пересмотреть.
Вторая диаграмма позволяет выявить проблему до начала работ над кодом - это и есть польза проектирования.
Однако, бывают случаи, когда архитектор неправильно воспринимает семантику схемы и в результате в работу уходит проект, который не может быть реализован на практике. Но это уже другая история.
Нам же важно понять, что хорошая схема должна быть настолько информативной, чтобы ответить на следующие вопросы:
- назначение элементов на схеме (и связанные с ними ограничения);
- взаимосвязь (влияние) элементов друг на друга;
- может ли элемент быть исключен из схемы и какие последствия это будет иметь;
- может ли элемент быть заменен и какие последствия это будет иметь;
- можно ли на основе схемы построить истинные утверждения, а не просто сформулировать абстрактные догадки.
UPD. Примеры в данном случае оба показывают неудачные кейсы, первый пример показывает "отсутствие смысла", а второй имеет смысл, но при этом нарушена логика, так как наследовать машину от автобуса - неверно. Как раз наличие во втором примере семантики, позволяет нам увидить ошибку на этапе проектирования.
100 x
100 х
100 х
#знания #проектирование
SOER | PRO | Boosty
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Vasiniyo
Конечно можно!
Архитектура:
1. Требования:
a. Функциональные
b. Нефункциональные
c. Производные
d. Пользовательские истории
2. Принципы:
a. Границы (толстые, тонкие)
b. YAGNI
c. KISS
d. DRY
3. Подходы:
a. Проектные
b. Продуктовые
4. Методология:
a. DDD (тактика, стратегия)
b. Agile (SCRUM, экстремальное программирование)
c. Классический подход (водопад):
I. Сверху вниз
II. Снизу вверх
5. Процессы:
a. Документирование (BPMN, UML)
b. Проектирование (ADR, C4)
c. Выпуск (версионирование, CI/CD)
6. [Проектирование и разработка] Уровень кода:
a. Шаблоны проектирования (GoF)
b. Парадигмы:
I. ООП (SOLID, GRASP, DI)
II. ФП
7. [Проектирование и разработка] Уровень приложения:
a. Концепции:
I. Реактивная архитектура
II. Чистая архитектура
III. Порты и адаптеры
IV. Feature Sliced
b. Структура:
I. Монолит
II. Сервис
III. Микросервис
IV. Микроядро/плагин
c. Данные:
I. Потоки данных (CQRS, Конвейер/pipe, pub/sub, SAGA)
II. Целостность (BASE, ACID)
8. [Проектирование и разработка] Системный уровень:
a. Данные (Data Lake, Data Mesh)
9. Уровень предприятия:
a. ITIL
b. PRINCE2
10. Облачная архитектура
Архитектура:
1. Требования:
a. Функциональные
b. Нефункциональные
c. Производные
d. Пользовательские истории
2. Принципы:
a. Границы (толстые, тонкие)
b. YAGNI
c. KISS
d. DRY
3. Подходы:
a. Проектные
b. Продуктовые
4. Методология:
a. DDD (тактика, стратегия)
b. Agile (SCRUM, экстремальное программирование)
c. Классический подход (водопад):
I. Сверху вниз
II. Снизу вверх
5. Процессы:
a. Документирование (BPMN, UML)
b. Проектирование (ADR, C4)
c. Выпуск (версионирование, CI/CD)
6. [Проектирование и разработка] Уровень кода:
a. Шаблоны проектирования (GoF)
b. Парадигмы:
I. ООП (SOLID, GRASP, DI)
II. ФП
7. [Проектирование и разработка] Уровень приложения:
a. Концепции:
I. Реактивная архитектура
II. Чистая архитектура
III. Порты и адаптеры
IV. Feature Sliced
b. Структура:
I. Монолит
II. Сервис
III. Микросервис
IV. Микроядро/плагин
c. Данные:
I. Потоки данных (CQRS, Конвейер/pipe, pub/sub, SAGA)
II. Целостность (BASE, ACID)
8. [Проектирование и разработка] Системный уровень:
a. Данные (Data Lake, Data Mesh)
9. Уровень предприятия:
a. ITIL
b. PRINCE2
10. Облачная архитектура
🔥73👍25
Встреча в Сочи
Хочу провести ежегодную встречу в Сочи со всеми желающими. Если у вас есть желание и возможность приехать на встречу, то пишите на @soerdev место и время определим вместе с вами.💡
Хочу провести ежегодную встречу в Сочи со всеми желающими. Если у вас есть желание и возможность приехать на встречу, то пишите на @soerdev место и время определим вместе с вами.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11
Forwarded from Радикальная идея
Стоит ли учить [framework name]?
Меня часто спрашивают, стоит ли что-то учить - какой-то фреймворк, какую-то библиотеку, паттерн, язык программирования и тд.
По этому поводу у меня есть радикальная идея: не нужно “учить” фреймворк. Все, что нужно выучить, вернее, освоить - это навык программировать. Навык программировать заключается в том, чтобы отображать объекты реального мира в виде абстракций, а также оперировать ими. Фреймворки, библиотеки и паттерны представляют собой лишь очередной способ делать это удобно. Возможно, для кого-то эта идея будет слишком радикальной, но на самом деле фреймворки, паттерны, библиотеки не рождаются из полного хаоса, они рождаются из удобных и практичных способов оперировать данными.
Поэтому не нужно “учить” очередной фреймворк; однако изучение новых фреймворков, библиотек и языков помогает качать главный навык - навык программировать, отсюда вытекает следующее: нужно учить программирование, а это удобно делать при изучении новых фреймворков, библиотек, языков и паттернов.
Меня часто спрашивают, стоит ли что-то учить - какой-то фреймворк, какую-то библиотеку, паттерн, язык программирования и тд.
По этому поводу у меня есть радикальная идея: не нужно “учить” фреймворк. Все, что нужно выучить, вернее, освоить - это навык программировать. Навык программировать заключается в том, чтобы отображать объекты реального мира в виде абстракций, а также оперировать ими. Фреймворки, библиотеки и паттерны представляют собой лишь очередной способ делать это удобно. Возможно, для кого-то эта идея будет слишком радикальной, но на самом деле фреймворки, паттерны, библиотеки не рождаются из полного хаоса, они рождаются из удобных и практичных способов оперировать данными.
Поэтому не нужно “учить” очередной фреймворк; однако изучение новых фреймворков, библиотек и языков помогает качать главный навык - навык программировать, отсюда вытекает следующее: нужно учить программирование, а это удобно делать при изучении новых фреймворков, библиотек, языков и паттернов.
🔥77👍37🤡9🤓6👌3✍2😁2🤯2❤1👎1💯1
Чему учит DataMesh архитектура
В современном мире быть архитектором - значит подмечать архитектурные идеи и тренды, которые существую в индустрии. Я переодически анализирую, что происходит вокруг, вот какие мысли у меня возникли в связи с анализом DataMesh архитектуры.
Тренд №1 Децентрализация
Век конвейрной обработки данных прошел, сейчас наиболее востребованы децентрализованные архитектуры. Если раньше инженеры работали над тем, чтобы создавать некую последовательность обработки данных (pipe), собирая их из нескольких источников, а затем хранили и обрабатывали по строгим правилам, да еще по итогу проводя всякие сложные процедуры по типу контроля целостности, то сейчас речь все больше идет о децентрализации, где в основе лежат домены данных и доступы к ним через API.
Тренд №2 API-интерфейсы
Децентрализованные данные могут подвергаться предварительной обработке (очистка, агрегация, архивация и т.д.) для повешения общей скорости работы, но в целом идея в том, чтобы хранить данные максимально полно в сыром виде, а каждый потребитель может используя API получить нужную порцию в нужном представлении.
Тренд №3 Владельцы и потребители - это домены
Идея в том, чтобы разделить владение данными на уровне доменов, где владельцы данных отвечают за предоставление API к своим данным, при этом они могут быть потребителями данных других доменов (да и в своем домене они могут вести себя и как владельцы, и как потребители)
Размытая грань между потреблением и владением - это очень мощный инструмент децентрализации.
Тренд №4 Федеративное управление
Вишенка на торте - общие правила и паттерны по которым работают все домены, что позволяет еще больше расширить возможности потребления данных и скрыть нюансы внутренней реализации.
Вывод
Обычно DataMesh рассматривают как подход для управления аналитическими данными, в рамках крупной организация со зрелыми процессами управления, но если вдуматься, то ровно те же идеи используются в реализации современных сервисных подходов в рамках веб-архитектур и эти идеи формируют новые тренды, которые находят свое применение в современных решениях.
По сути весь веб стал работать как большая DataMesh архитектура - есть децентрализованные сервисы (домены), есть продуманные API, есть владельцы данных. Если сравнить микросервисную архитектуру и DataMesh? Разница только в том, что микросервисы - для проектных OLTP решений, а DataMesh - для аналитических данных OLAP систем, но принципы (читай "тренды") одинаковые.
SOER | PRO | Boosty
В современном мире быть архитектором - значит подмечать архитектурные идеи и тренды, которые существую в индустрии. Я переодически анализирую, что происходит вокруг, вот какие мысли у меня возникли в связи с анализом DataMesh архитектуры.
Тренд №1 Децентрализация
Век конвейрной обработки данных прошел, сейчас наиболее востребованы децентрализованные архитектуры. Если раньше инженеры работали над тем, чтобы создавать некую последовательность обработки данных (pipe), собирая их из нескольких источников, а затем хранили и обрабатывали по строгим правилам, да еще по итогу проводя всякие сложные процедуры по типу контроля целостности, то сейчас речь все больше идет о децентрализации, где в основе лежат домены данных и доступы к ним через API.
Тренд №2 API-интерфейсы
Децентрализованные данные могут подвергаться предварительной обработке (очистка, агрегация, архивация и т.д.) для повешения общей скорости работы, но в целом идея в том, чтобы хранить данные максимально полно в сыром виде, а каждый потребитель может используя API получить нужную порцию в нужном представлении.
Тренд №3 Владельцы и потребители - это домены
Идея в том, чтобы разделить владение данными на уровне доменов, где владельцы данных отвечают за предоставление API к своим данным, при этом они могут быть потребителями данных других доменов (да и в своем домене они могут вести себя и как владельцы, и как потребители)
Размытая грань между потреблением и владением - это очень мощный инструмент децентрализации.
Тренд №4 Федеративное управление
Вишенка на торте - общие правила и паттерны по которым работают все домены, что позволяет еще больше расширить возможности потребления данных и скрыть нюансы внутренней реализации.
Вывод
Обычно DataMesh рассматривают как подход для управления аналитическими данными, в рамках крупной организация со зрелыми процессами управления, но если вдуматься, то ровно те же идеи используются в реализации современных сервисных подходов в рамках веб-архитектур и эти идеи формируют новые тренды, которые находят свое применение в современных решениях.
По сути весь веб стал работать как большая DataMesh архитектура - есть децентрализованные сервисы (домены), есть продуманные API, есть владельцы данных. Если сравнить микросервисную архитектуру и DataMesh? Разница только в том, что микросервисы - для проектных OLTP решений, а DataMesh - для аналитических данных OLAP систем, но принципы (читай "тренды") одинаковые.
SOER | PRO | Boosty
👍49🤔9
Пополнил папку участников Соер.Клуба, добавил Андрея - автор канала Kobezzza.
Мне нравится, что в клубе собираются крутые соеры, у которых многому можно научиться. Пока не было ни одного отказа от приглашения в клуб. Это для меня многое значит, спасибо ребятам, что делаете свое сложное дело по развитию АйТи.
Мне нравится, что в клубе собираются крутые соеры, у которых многому можно научиться. Пока не было ни одного отказа от приглашения в клуб. Это для меня многое значит, спасибо ребятам, что делаете свое сложное дело по развитию АйТи.
Telegram
Соер.Клуб
S0ER invites you to add the folder “Соер.Клуб”, which includes 9 chats.