Роль «Архитектор»
- определение и взаимодействие со стекхолдерами
- определение требований
- определение ограничений
- построение архитектуры соответствующей требованиям и ограничениям
Специализации архитектора:
- product architect – отвечает за поставку продукта внешним заказчикам или стекхолдерам
- domain architect – основные функции по построению архитектуры высокого уровня (бизнес-архитектура, архитектура данных и т.д.)
- solution architect - отвечает за архитектуру на уровне решения
- enterprise architect – высокоуровневые задачи управления предприятием – продажи, маркетинг, продукты, сервисы и т.д.
Подходы к проектированию архитектуры:
- Каскадная модель (waterfall) – модель при которой архитектор проходит стандартные фазы: анализ требований, проектирование, реализация и т.д.
- Итеративный подход – разделение проектирования на итерации (обычно каждая итерация – это отдельный вопрос проектирование) и проход по каждой итерации как по самостоятельному проекту
- Agile - непрерывный цикл проектирования включающий «дизайн», «разработка и тестирование», «развертывание», «анализ».
Важные элементы архитектуры:
- Бизнес цели и «драйверы» - конкретны задачи, которые хочет решить бизнес, а так же способы их достижения;
- Архитектурный контекст – это описание важных элементов архитектуры, которые определяют ее взаимодействие с внешним миром, а так же ее функциональные возможности. Описывается коротко, с достаточной для понимания сути детализацией, без жаргона и скрытой «магии»;
- Архитектурные вопросы – описание того какие проблемы существуют и как они решаются в рамках построения системы, а также ограничения которые нужно учитывать. Описание как правило включает архитектурные цели, функциональные требования, архитектурные требования и т.д.
- Архитектурные принципы – это принципы построения системы, ее каркас, а так же подсказка какие решения в рамках архитектур должны приниматься. Принципы должны быть конструктивными, обдуманными, существенными.
Архитектурные паттерны как правило бьются на три группы:
- архитектурные стили – паттерн описывающий архитектуру на системном уровне, основное отличие в том что стиль рассматривает систему целиком, не концентрируясь на деталях. Стиль как правило описывается в терминах «архитектурных элементов» их взаимодействии и ограничениях.
- шаблон проектирования – это более конкретное решение, которое направлено на решение специфического вопроса и содержит описание какой-то конкретной ситуации;
- идиомы языка программирования – шаблоны для реализации на уровне языка программирования, учитывающие особенности языка и реализующие лучшие практики.
Распространённые архитектурные стили:
- Pipes and filters
- Client/Server
- Tiered Computing (отличается от Layered тем, что порядок взаимодействия tier-ов может быть любым)
- Peer-to-Peer
- Layered Implementation
- Publisher/Subscriber (реактивные архитектуры)
- Asynchronous Data Replication (отличается от pub/sub тем, что предназначена для синхронизации источников данных)
- Distribution Tree (publisher -> distributor -> consumer)
- Integration Hub (отличается от Data Replication тем, что синхронизация данных идет между системами, а не репликами БД)
- Tuple Space
Важные артефакты описания архитектуры:
- Архитектурное описание (общее описание системы)
- Моделирование (модель отражает упрощенное представление реальной бизнес задачи и служит для выстраивания аспектов системы)
- Сценарии использования готовой системы
- Валидация (проверка технических и логических моментов на корректность)
- определение и взаимодействие со стекхолдерами
- определение требований
- определение ограничений
- построение архитектуры соответствующей требованиям и ограничениям
Специализации архитектора:
- product architect – отвечает за поставку продукта внешним заказчикам или стекхолдерам
- domain architect – основные функции по построению архитектуры высокого уровня (бизнес-архитектура, архитектура данных и т.д.)
- solution architect - отвечает за архитектуру на уровне решения
- enterprise architect – высокоуровневые задачи управления предприятием – продажи, маркетинг, продукты, сервисы и т.д.
Подходы к проектированию архитектуры:
- Каскадная модель (waterfall) – модель при которой архитектор проходит стандартные фазы: анализ требований, проектирование, реализация и т.д.
- Итеративный подход – разделение проектирования на итерации (обычно каждая итерация – это отдельный вопрос проектирование) и проход по каждой итерации как по самостоятельному проекту
- Agile - непрерывный цикл проектирования включающий «дизайн», «разработка и тестирование», «развертывание», «анализ».
Важные элементы архитектуры:
- Бизнес цели и «драйверы» - конкретны задачи, которые хочет решить бизнес, а так же способы их достижения;
- Архитектурный контекст – это описание важных элементов архитектуры, которые определяют ее взаимодействие с внешним миром, а так же ее функциональные возможности. Описывается коротко, с достаточной для понимания сути детализацией, без жаргона и скрытой «магии»;
- Архитектурные вопросы – описание того какие проблемы существуют и как они решаются в рамках построения системы, а также ограничения которые нужно учитывать. Описание как правило включает архитектурные цели, функциональные требования, архитектурные требования и т.д.
- Архитектурные принципы – это принципы построения системы, ее каркас, а так же подсказка какие решения в рамках архитектур должны приниматься. Принципы должны быть конструктивными, обдуманными, существенными.
Архитектурные паттерны как правило бьются на три группы:
- архитектурные стили – паттерн описывающий архитектуру на системном уровне, основное отличие в том что стиль рассматривает систему целиком, не концентрируясь на деталях. Стиль как правило описывается в терминах «архитектурных элементов» их взаимодействии и ограничениях.
- шаблон проектирования – это более конкретное решение, которое направлено на решение специфического вопроса и содержит описание какой-то конкретной ситуации;
- идиомы языка программирования – шаблоны для реализации на уровне языка программирования, учитывающие особенности языка и реализующие лучшие практики.
Распространённые архитектурные стили:
- Pipes and filters
- Client/Server
- Tiered Computing (отличается от Layered тем, что порядок взаимодействия tier-ов может быть любым)
- Peer-to-Peer
- Layered Implementation
- Publisher/Subscriber (реактивные архитектуры)
- Asynchronous Data Replication (отличается от pub/sub тем, что предназначена для синхронизации источников данных)
- Distribution Tree (publisher -> distributor -> consumer)
- Integration Hub (отличается от Data Replication тем, что синхронизация данных идет между системами, а не репликами БД)
- Tuple Space
Важные артефакты описания архитектуры:
- Архитектурное описание (общее описание системы)
- Моделирование (модель отражает упрощенное представление реальной бизнес задачи и служит для выстраивания аспектов системы)
- Сценарии использования готовой системы
- Валидация (проверка технических и логических моментов на корректность)
Вывод: книга состоит из двух частей в первой части идет рассмотрение основных архитектурных концепций и других вопросов построения архитектуры, во второй части идет каталог архитектурных представлений и перспектив, которые рассматривают конкретные реализации архитектур. В книге не рассмотрены современные архитектуры, такие как микросервисная или варианты реактивных архитектур. Это связана с тем, что книга довольно старая, поэтому есть некоторые моменты, которые не соответствуют сегодняшнему дню. Но в целом книга дает основное понимание работы архитектора – это работа с заказчиком, анализ и обобщение требований, выделение главного, и только в последнюю очередь использование конкретных паттернов. Рекомендую книгу к прочтению.
Practical Microservices Architectural Patterns
Event-Based Java Microservices with Spring Boot and Spring Cloud
Вводная часть книги содержит общее описание классического подхода к построению архитектуры систем:
- менйфрейм архитектура, когда есть центральный супер компьютер и куча «тупых» терминалов, которые отображают данные, но весь стейт хранится на сервере;
- клиент/серверная архитектура, когда стейт хранится на клиента, а тяжелые операции выполняются на сервере
- 3-х уровневая архитектура системы – классическое разделение на клиентский уровень, бизнес логику (средний уровень) и данные
- многоуровневая архитектура – выделение из среднего уровня несколько промежуточных уровней.
В большинстве случаев архитектура систем используется сетевую инфраструктуру для взаимодействия между клиентом и сервером. Для этого есть несколько стандартных решений:
- соединение точка/точка
- брокер сообщений
- общая шина сообщений
В свою очередь, архитектурные уровни, входящие в систему, могут разделяться на слои приложения, которые бьются на модули. Модульный подход – классика построения сложных систем.
У модульного подхода несколько недостатков:
– ад зависимостей, которые с ростом системы все труднее поддаются управлению;
- ограничения масштабирования, которые вытекают из предыдущего пункта;
- монолитность на уровне системы, несмотря на то что внутри приложение разделено на слои и модули, разделение уровней системы невозможно и они развертываются как единый элемент.
Основные принципы построение масштабируемых систем:
- Стейтлес дизайн – без единой точки состояния система может тиражироваться на любое количество узлов;
- Использование принципа разделяй и властвуй – способ разбить монолит на части и вынести части за пределы единого узла развертывания;
Альтернативой классическим монолитным подходам выступает архитектура с независимыми модулями, которая имеет два основных преимущества:
- параллельная разработка
- разделенная публикация
Основная проблема такого решение – организация взаимодействия между модулями. При синхронном взаимодействии возникают длительные периоды когда модуль ничего не делает ожидая ответ, поэтому асинхронная природа запросов – вынужденное зло.
Наиболее продвинутым вариантом построения архитектуры с независимыми модуля является микросервисная архитектура, у нее следующие особенности:
- общение сервисом посредством сообщений, которые передаются через сетевую инфраструктуру
- разнородная, независимая природа сервисов (могут быть реализованы на разных языках, в разных модулях развертывания)
- сосредоточенность на бизнес задачах
- размер сервиса небольшой, ограничен решением маленькой задачи, с возможностью независимой публикации сервиса и его обновления.
В основе взаимодействия микросервисов лежат REST-запросы и JSON нотация для представления данных. Но так же может быть использован другой формат, например XML.
MASA (Mesh App and Service Architecture) – архитектурное решение, которое позволяет объединить и организовать различных пользователей, с различными девайсами, работающих на различные типах сетей. В такой архитектуре бесшовно должны работать мобильные приложения, веб-приложения, десктопные приложения, IOT устройства.
Варианты построения облачной инфраструктуры:
Infrastructure as a Service — одна из моделей обслуживания в облачных вычислениях, по которой потребителям предоставляются по подписке фундаментальные информационно-технологические ресурсы — виртуальные серверы с заданной вычислительной мощностью, операционной системой и доступом к сети
Platform as a Service — модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию информационно-технологических платформ: операционных систем, систем управления базами данных, связующему программному обеспечению, средствам разработки и тестирования
Software as a Service — одна из форм облачных вычислений, модель обслуживания, при которой подписчикам предоставляется готовое прикладное программное обеспечение, полностью обслуживаемое провайдером
Варианты виртуализации: виртуальные серверы или контейнеры.
#microservice
Event-Based Java Microservices with Spring Boot and Spring Cloud
Вводная часть книги содержит общее описание классического подхода к построению архитектуры систем:
- менйфрейм архитектура, когда есть центральный супер компьютер и куча «тупых» терминалов, которые отображают данные, но весь стейт хранится на сервере;
- клиент/серверная архитектура, когда стейт хранится на клиента, а тяжелые операции выполняются на сервере
- 3-х уровневая архитектура системы – классическое разделение на клиентский уровень, бизнес логику (средний уровень) и данные
- многоуровневая архитектура – выделение из среднего уровня несколько промежуточных уровней.
В большинстве случаев архитектура систем используется сетевую инфраструктуру для взаимодействия между клиентом и сервером. Для этого есть несколько стандартных решений:
- соединение точка/точка
- брокер сообщений
- общая шина сообщений
В свою очередь, архитектурные уровни, входящие в систему, могут разделяться на слои приложения, которые бьются на модули. Модульный подход – классика построения сложных систем.
У модульного подхода несколько недостатков:
– ад зависимостей, которые с ростом системы все труднее поддаются управлению;
- ограничения масштабирования, которые вытекают из предыдущего пункта;
- монолитность на уровне системы, несмотря на то что внутри приложение разделено на слои и модули, разделение уровней системы невозможно и они развертываются как единый элемент.
Основные принципы построение масштабируемых систем:
- Стейтлес дизайн – без единой точки состояния система может тиражироваться на любое количество узлов;
- Использование принципа разделяй и властвуй – способ разбить монолит на части и вынести части за пределы единого узла развертывания;
Альтернативой классическим монолитным подходам выступает архитектура с независимыми модулями, которая имеет два основных преимущества:
- параллельная разработка
- разделенная публикация
Основная проблема такого решение – организация взаимодействия между модулями. При синхронном взаимодействии возникают длительные периоды когда модуль ничего не делает ожидая ответ, поэтому асинхронная природа запросов – вынужденное зло.
Наиболее продвинутым вариантом построения архитектуры с независимыми модуля является микросервисная архитектура, у нее следующие особенности:
- общение сервисом посредством сообщений, которые передаются через сетевую инфраструктуру
- разнородная, независимая природа сервисов (могут быть реализованы на разных языках, в разных модулях развертывания)
- сосредоточенность на бизнес задачах
- размер сервиса небольшой, ограничен решением маленькой задачи, с возможностью независимой публикации сервиса и его обновления.
В основе взаимодействия микросервисов лежат REST-запросы и JSON нотация для представления данных. Но так же может быть использован другой формат, например XML.
MASA (Mesh App and Service Architecture) – архитектурное решение, которое позволяет объединить и организовать различных пользователей, с различными девайсами, работающих на различные типах сетей. В такой архитектуре бесшовно должны работать мобильные приложения, веб-приложения, десктопные приложения, IOT устройства.
Варианты построения облачной инфраструктуры:
Infrastructure as a Service — одна из моделей обслуживания в облачных вычислениях, по которой потребителям предоставляются по подписке фундаментальные информационно-технологические ресурсы — виртуальные серверы с заданной вычислительной мощностью, операционной системой и доступом к сети
Platform as a Service — модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию информационно-технологических платформ: операционных систем, систем управления базами данных, связующему программному обеспечению, средствам разработки и тестирования
Software as a Service — одна из форм облачных вычислений, модель обслуживания, при которой подписчикам предоставляется готовое прикладное программное обеспечение, полностью обслуживаемое провайдером
Варианты виртуализации: виртуальные серверы или контейнеры.
#microservice
CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи.
CQRS строится на базе двух концепций:
- команды
- события
#microservice
CQRS строится на базе двух концепций:
- команды
- события
#microservice
Для построения крупных распределенных приложений используется механизм обмена сообщениями. Процесс строится на принципе «положил в очередь/взял из очереди», обычно в роли места куда складываются сообщения выступает брокер сообщений.
Микросервис который «кладет» в очередь называется Producer
Микросервис который «берет» из очереди называется Consumer
AMQP — открытый протокол для передачи сообщений между компонентами системы
Высокая доступность при использовании микросервисов подразумевает планирование и определение сервисов, к которым предъявляются требования высокой доступности. Для этих сервисов должны быть определены возможные точки отказа и варианты восстановления.
Один из эффективных подходов – файлуре толеранс (принятие сбоев).
Уровень доступности определяется процентом времени в аптайме, 100% - 24/7
Основная идея для повышения доступности системы – дублирование основных элементов архитектуры.
Сюда относится:
- балансировка DNS
- дублирование интернет провайдеров (ISP), использование BGP протокола
- дублирование СУБД
- дублирование инфраструктуры для развертывания микросервисов
Микросервис который «кладет» в очередь называется Producer
Микросервис который «берет» из очереди называется Consumer
AMQP — открытый протокол для передачи сообщений между компонентами системы
Высокая доступность при использовании микросервисов подразумевает планирование и определение сервисов, к которым предъявляются требования высокой доступности. Для этих сервисов должны быть определены возможные точки отказа и варианты восстановления.
Один из эффективных подходов – файлуре толеранс (принятие сбоев).
Уровень доступности определяется процентом времени в аптайме, 100% - 24/7
Основная идея для повышения доступности системы – дублирование основных элементов архитектуры.
Сюда относится:
- балансировка DNS
- дублирование интернет провайдеров (ISP), использование BGP протокола
- дублирование СУБД
- дублирование инфраструктуры для развертывания микросервисов
Для повышения производительности микросервисов рекомендуется:
- использовать асинхронные http запросы
- Protocol Buffers — протокол сериализации структурированных данных, предложенный Google как эффективная бинарная альтернатива текстовому формату XML. Основные задачи – маршалинг/демаршалинг данных
Для управления состоянием системы построенной на базе микросервисов часто используется Event Driven Architecture (EDA)
EDA обычно включает в себя отправителей и получателей событий.
Событие - это факт, который произошел и имеет место быть. При этом оповещение о событии и событие – это два разных понятия. И часто их путают, когда возникновение событие связывают неразрывно с механизмом оповещений.
EDA:
- Каналы
o Передача событий
o Поддержание очереди событий
- Отправители (emmiters/agents/source)
o Генерация событий
o Детекция событий
o Сбор событий
o Отправка событий
- Получатели (sinks/consumers)
o Прием и обработка событий
В EDA архитектуре основой является BASE (Basically Available, Soft State, Eventually Consistent) Systems.
Для обеспечения взаимодействия между микросервисами используется транзакционный подход. При этом каждая транзакция должна соответствовать ACID.
Транзакционные модели:
- плоская – последовательное выполнение транзакций с единой точкой отката
- вложенная – каждая транзакция может создавать дочерние транзакции, при этом откат родительской транзакции несет за собой откат дочерних транзакций, а откат дочерних транзакции влечет необходимость принятия решения об откате на уровне родительской транзакции
- цепочки транзакций – каждая последующая транзакция зависит от предыдущей
- шаблон saga – тоже самое что вложенная модель, но каждая родительская транзакция имеет специальные «компенсационные» транзакции.
Механизмы изоляции транзакций:
- блокировка
- сериализация
Варианты транзакций:
- ACID транзакции (единственные кто может гарантировать целостность данных)
- BASE транзакции (используют принцип «целостность в конечном итоге»)
- использовать асинхронные http запросы
- Protocol Buffers — протокол сериализации структурированных данных, предложенный Google как эффективная бинарная альтернатива текстовому формату XML. Основные задачи – маршалинг/демаршалинг данных
Для управления состоянием системы построенной на базе микросервисов часто используется Event Driven Architecture (EDA)
EDA обычно включает в себя отправителей и получателей событий.
Событие - это факт, который произошел и имеет место быть. При этом оповещение о событии и событие – это два разных понятия. И часто их путают, когда возникновение событие связывают неразрывно с механизмом оповещений.
EDA:
- Каналы
o Передача событий
o Поддержание очереди событий
- Отправители (emmiters/agents/source)
o Генерация событий
o Детекция событий
o Сбор событий
o Отправка событий
- Получатели (sinks/consumers)
o Прием и обработка событий
В EDA архитектуре основой является BASE (Basically Available, Soft State, Eventually Consistent) Systems.
Для обеспечения взаимодействия между микросервисами используется транзакционный подход. При этом каждая транзакция должна соответствовать ACID.
Транзакционные модели:
- плоская – последовательное выполнение транзакций с единой точкой отката
- вложенная – каждая транзакция может создавать дочерние транзакции, при этом откат родительской транзакции несет за собой откат дочерних транзакций, а откат дочерних транзакции влечет необходимость принятия решения об откате на уровне родительской транзакции
- цепочки транзакций – каждая последующая транзакция зависит от предыдущей
- шаблон saga – тоже самое что вложенная модель, но каждая родительская транзакция имеет специальные «компенсационные» транзакции.
Механизмы изоляции транзакций:
- блокировка
- сериализация
Варианты транзакций:
- ACID транзакции (единственные кто может гарантировать целостность данных)
- BASE транзакции (используют принцип «целостность в конечном итоге»)
Наибольшие проблемы в сопровождении вызывают распределенные транзакции, значительная часть времени на разработку микросервисной архитектуры тратиться на проработку сценариев получения и распространения распределенных транзакций.
Преимущество нужно отдавать локальным транзакциям, избегая распределенных транзакции как можно дольше.
Для управления платформой на базе микросервисов используются «конфиг серверы». Конфиг сервер может быть микросервисом в задачи которого входит распространение конфигурации системы между другими микросервисами.
Стек:
- конфиг сервер - ZooKeper
- регистратор сервисов - Eureka
- API шлюз - Zuul
Вывод: книга – отличное пособие для Java разработчиков, желающих развернуть микросервисную архитектуру у себя на проекте. Большая часть книги – это описание конкретных примеров использования и создания микросервисов на базе Java Spring. Около трети книги рассматривает теоретические аспекты построения микросервисной архитектуры. В книге много иллюстрирующих изображений, котороые помогают понять как может быть описана архитектура микросервисной системы.
Преимущество нужно отдавать локальным транзакциям, избегая распределенных транзакции как можно дольше.
Для управления платформой на базе микросервисов используются «конфиг серверы». Конфиг сервер может быть микросервисом в задачи которого входит распространение конфигурации системы между другими микросервисами.
Стек:
- конфиг сервер - ZooKeper
- регистратор сервисов - Eureka
- API шлюз - Zuul
Вывод: книга – отличное пособие для Java разработчиков, желающих развернуть микросервисную архитектуру у себя на проекте. Большая часть книги – это описание конкретных примеров использования и создания микросервисов на базе Java Spring. Около трети книги рассматривает теоретические аспекты построения микросервисной архитектуры. В книге много иллюстрирующих изображений, котороые помогают понять как может быть описана архитектура микросервисной системы.
Конспект книги «Functional and reactive domain modeling»
Книга начинается с краткого введения в Доменно-ориентированный дизайн (DDD) кратко рассмотрены следующие моменты:
Доменная модель (модель предметной области) – это вся информация, необходимая для перевода бизнес-задачи на язык программирования.
Bounded context (ограниченный контекст) – реализация принципа слабого зацепления на уровне модулей. Та граница внутри которой существует модель предметной области.
Domain Driven design разделяет два понятия Entity (Сущность) и Value Object (объект-значение)
Value Object – это объект связанный с конкретным значением, которое является его состоянием.
Entity – понятие более выского уровня, относящееся к доменной модели и имеющее свою собственную идентичность (неповторимость)
Service (сервис) в том числе доменный сервис – понятие более высокого уровня объединяет несколько сущностей и объектов-значений.
Сущности имеют свою собственную, внутренне присущую им идентичность. Объекты-значения — нет.
Объект-значение имеет внутреннюю иммутабельность и могут свободно перераспределяться между сущностями
Понятие эквивалентности идентификаторов относится к сущностям; понятие структурной эквивалентности — к объектам-значениям; ссылочной эквивалентности — к обоим.
Сущности имеют историю; у объектов-значений нулевой жизненный цикл.
Объект-значение всегда должен принадлежать одной или нескольким сущностям, он не может жить собственной жизнью.
Объекты-значения должны быть неизменяемыми; сущности почти всегда изменяемы.
Чтобы распознать объект-значение, мысленно замените его на integer.
Объекты-значения не должны иметь собственной таблицы в БД.
Предпочитайте объекты-значения сущностям при моделивании домена.
Доменный объект - это объекты в объектно-ориентированных компьютерных программах, выражающие сущности из модели предметной области
Доменные объекты могут создаваться через фабрики, которые создают агрегаты.
Агрегат является самым сложным из всех тактических инструментов DDD. Агрегатом называется кластер из объектов сущностей или значений. То есть эти объекты рассматриваются как единое целое с точки зрения изменения данных.
Агрегаты сохраняются в репозиториях, которые представлены базами данных (неважно SQL или NO SQL)
Словарь – важный элемент DDD содержит основные определения и термины предметной области.
Основные принципы проектирования доменных моделей в функциональном стиле
- Модель иммутабельна и представлена через алгебраические типы данных (АТД)
- поведение модели реализуется через функции в модуле, где модуль представляет из себя блок бизнес логики
- поведение оперирует над АДТ
Далее в книге идет обзорное рассмотрение функциональной парадигмы.
В основе функционального программирования лежит функциональная композиция. Например, f(g(h)) – это функциональная композиция функций одной переменной. Идея в том, что целое состоит из взаимодействия частей.
Функции высшего порядка – такие функции, которые принимают в качестве аргументов другие функции. Частным примером является функция map которая применят к списку значений какую-либо функцию и возвращает список измененных значений. Такие функции называются «комбинаторы».
Сайд эффект – любые действия функции, которые меняют внешнее окружение.
Чистые функции – такие функции, которые не имеют сайд эффектов.
Книга начинается с краткого введения в Доменно-ориентированный дизайн (DDD) кратко рассмотрены следующие моменты:
Доменная модель (модель предметной области) – это вся информация, необходимая для перевода бизнес-задачи на язык программирования.
Bounded context (ограниченный контекст) – реализация принципа слабого зацепления на уровне модулей. Та граница внутри которой существует модель предметной области.
Domain Driven design разделяет два понятия Entity (Сущность) и Value Object (объект-значение)
Value Object – это объект связанный с конкретным значением, которое является его состоянием.
Entity – понятие более выского уровня, относящееся к доменной модели и имеющее свою собственную идентичность (неповторимость)
Service (сервис) в том числе доменный сервис – понятие более высокого уровня объединяет несколько сущностей и объектов-значений.
Сущности имеют свою собственную, внутренне присущую им идентичность. Объекты-значения — нет.
Объект-значение имеет внутреннюю иммутабельность и могут свободно перераспределяться между сущностями
Понятие эквивалентности идентификаторов относится к сущностям; понятие структурной эквивалентности — к объектам-значениям; ссылочной эквивалентности — к обоим.
Сущности имеют историю; у объектов-значений нулевой жизненный цикл.
Объект-значение всегда должен принадлежать одной или нескольким сущностям, он не может жить собственной жизнью.
Объекты-значения должны быть неизменяемыми; сущности почти всегда изменяемы.
Чтобы распознать объект-значение, мысленно замените его на integer.
Объекты-значения не должны иметь собственной таблицы в БД.
Предпочитайте объекты-значения сущностям при моделивании домена.
Доменный объект - это объекты в объектно-ориентированных компьютерных программах, выражающие сущности из модели предметной области
Доменные объекты могут создаваться через фабрики, которые создают агрегаты.
Агрегат является самым сложным из всех тактических инструментов DDD. Агрегатом называется кластер из объектов сущностей или значений. То есть эти объекты рассматриваются как единое целое с точки зрения изменения данных.
Агрегаты сохраняются в репозиториях, которые представлены базами данных (неважно SQL или NO SQL)
Словарь – важный элемент DDD содержит основные определения и термины предметной области.
Основные принципы проектирования доменных моделей в функциональном стиле
- Модель иммутабельна и представлена через алгебраические типы данных (АТД)
- поведение модели реализуется через функции в модуле, где модуль представляет из себя блок бизнес логики
- поведение оперирует над АДТ
Далее в книге идет обзорное рассмотрение функциональной парадигмы.
В основе функционального программирования лежит функциональная композиция. Например, f(g(h)) – это функциональная композиция функций одной переменной. Идея в том, что целое состоит из взаимодействия частей.
Функции высшего порядка – такие функции, которые принимают в качестве аргументов другие функции. Частным примером является функция map которая применят к списку значений какую-либо функцию и возвращает список измененных значений. Такие функции называются «комбинаторы».
Сайд эффект – любые действия функции, которые меняют внешнее окружение.
Чистые функции – такие функции, которые не имеют сайд эффектов.
👍2
Подстановочная модель вычислений (substitution model) – модель вычислений при которой происходит подстановка значений констант на место их идентификаторов
Ссылочная прозрачность и ссылочная непрозрачность — это свойства частей компьютерных программ. Выражение называется ссылочно прозрачным, если его можно заменить соответствующим значением без изменения поведения программы
Рассуждения в терминах эквивалентности (Equational reasoning) – парадигма в рамках которой и функции и их значения являются одним и тем же и их можно свободно заменять друг другом.
Реактивная модель
В рамках определения реактивной модели в книге раскрываются стандартные понятия.
Реактивная модель – модель ориентированная на потоки данных и распространение изменений. В основе модели лежит обмен сообщениями.
Основные атрибуты реактивной модели:
- отзывчивость (responsive) – реакция на действия пользователя
- эластичность (elastic) – возможность обрабатывать разную нагрузку
- отказоустойчивость (resilient) - устойчивость к ошибками
- обмен сообщениями и событиям
Обмен сообщениями подразумевает обмен событиями (Event) и командами (Command).
Доменные события обычно представлены одним из двух вариантов:
- идентификация по типу – каждому событию сопоставлен тип в системе
- собственное состояние – вся информация о событии находится внутри события.
Влияние событий обычно представлено одним из двух вариантов:
- система как снапшот – все события сразу изменяют состояние системы
- система как журнал изменений (Event log) – все события сохраняются и потом последовательно применяются к системе.
Далее в книге идет описание как в рамках языка Scala реализуются основные концепции управления и проводится связь между языком и перечисленными ранее парадигмами:
- управление «эффектами»
- управление задержками
- управление ошибками.
Основные момент связанные со Scala:
- Мощная система типов
- Функциональная парадигма как основная
- Алгебраические типы данных
- Модули как члены первого класса
Далее глубоко рассмотрены функциональные паттерны для реализации реактивных моделей, в основе лежат монады и функторы (примечание, без понимания монад и функторов читать раздел бессмысленно). Так же рассмотрены вопросы построения модулей и модулеризации приложения.
Способы создания реактивных доменных моделей
- promise и future - Под future обычно имеется в виду представление переменной, доступное только для чтения, а под promise — изменяемый контейнер с одиночным присваиванием, который передаёт значение future.
- явный обмен сообщениями
- модель акторов (например, на базе Akka) – стиль обмена «отправил и забыл» позволяет организовать асинхронное, событийно-ориентированное и неблокирующее взаимодействие. Акторы – однопоточные упрощенные модели вычислений. Конкурентность достигается за счет использования большого количества акторов.
- потоковая модель
Ссылочная прозрачность и ссылочная непрозрачность — это свойства частей компьютерных программ. Выражение называется ссылочно прозрачным, если его можно заменить соответствующим значением без изменения поведения программы
Рассуждения в терминах эквивалентности (Equational reasoning) – парадигма в рамках которой и функции и их значения являются одним и тем же и их можно свободно заменять друг другом.
Реактивная модель
В рамках определения реактивной модели в книге раскрываются стандартные понятия.
Реактивная модель – модель ориентированная на потоки данных и распространение изменений. В основе модели лежит обмен сообщениями.
Основные атрибуты реактивной модели:
- отзывчивость (responsive) – реакция на действия пользователя
- эластичность (elastic) – возможность обрабатывать разную нагрузку
- отказоустойчивость (resilient) - устойчивость к ошибками
- обмен сообщениями и событиям
Обмен сообщениями подразумевает обмен событиями (Event) и командами (Command).
Доменные события обычно представлены одним из двух вариантов:
- идентификация по типу – каждому событию сопоставлен тип в системе
- собственное состояние – вся информация о событии находится внутри события.
Влияние событий обычно представлено одним из двух вариантов:
- система как снапшот – все события сразу изменяют состояние системы
- система как журнал изменений (Event log) – все события сохраняются и потом последовательно применяются к системе.
Далее в книге идет описание как в рамках языка Scala реализуются основные концепции управления и проводится связь между языком и перечисленными ранее парадигмами:
- управление «эффектами»
- управление задержками
- управление ошибками.
Основные момент связанные со Scala:
- Мощная система типов
- Функциональная парадигма как основная
- Алгебраические типы данных
- Модули как члены первого класса
Далее глубоко рассмотрены функциональные паттерны для реализации реактивных моделей, в основе лежат монады и функторы (примечание, без понимания монад и функторов читать раздел бессмысленно). Так же рассмотрены вопросы построения модулей и модулеризации приложения.
Способы создания реактивных доменных моделей
- promise и future - Под future обычно имеется в виду представление переменной, доступное только для чтения, а под promise — изменяемый контейнер с одиночным присваиванием, который передаёт значение future.
- явный обмен сообщениями
- модель акторов (например, на базе Akka) – стиль обмена «отправил и забыл» позволяет организовать асинхронное, событийно-ориентированное и неблокирующее взаимодействие. Акторы – однопоточные упрощенные модели вычислений. Конкурентность достигается за счет использования большого количества акторов.
- потоковая модель
Акторы:
- извлекают сообщение из «почтового ящика»
- создают новых акторов
- обновляют собственное состояние
- отправляют сообщения другим акторам
Целостность доменных моделей
При использовании стандартного CRUD для хранения состояния моделей в реляционных СУБД есть одна проблема – в БД сохраняется конечный результат вычислений, при этом не существует возможности определить «как» этот результат был получен. Например, при выполнении цепочки банковских транзакций в БД сохраняется конечная цифра – баланс. Это проблема, так как не позволяет делать «трассировку» состояний. Это блокиурет возможность отследить исторические изменения, сделать откат транзакции и т.д. Так же реляционные БД обычно имеют существенные ограничения по гарантированию целостности данных за пределами одной ноды.
Чтобы избежать данных проблем используется два варианта моделей, обеспечивающих целостное состояние:
- CQRS – разделение операций чтения и записи на два потока
- Event sourcing – сохранения в БД не конечного состояния, а набора «событий», которые привели к этому состоянию.
Основные принципы доменного моделирования:
- мысли выражениями
- сначала абстракция, затем вычисления
- используй наиболее простую абстракцию, которая подходит
- показывай «что делать», скрывай «как делать»
- изолируй с помощью bounded context
- предпочитай future акторам
- прогнозирую на ближайшую перспективу
Вывод: книга обзорно рассматривает основные понятие связанные с функциональным программированием и DDD. Затем подробно показывает как с помощью основных инструментов SCALA реализовать DDD с помощью функционального программирования. В книге подробно рассматриваются основные паттерны и приемы функционального проектирования. Рассматриваются вопросы построения целостных моделей, вопросы тестирования. Книга требует хорошего понимания SCALA и функционального программирования, использовать книгу как учебник по SCALA не получится.
- извлекают сообщение из «почтового ящика»
- создают новых акторов
- обновляют собственное состояние
- отправляют сообщения другим акторам
Целостность доменных моделей
При использовании стандартного CRUD для хранения состояния моделей в реляционных СУБД есть одна проблема – в БД сохраняется конечный результат вычислений, при этом не существует возможности определить «как» этот результат был получен. Например, при выполнении цепочки банковских транзакций в БД сохраняется конечная цифра – баланс. Это проблема, так как не позволяет делать «трассировку» состояний. Это блокиурет возможность отследить исторические изменения, сделать откат транзакции и т.д. Так же реляционные БД обычно имеют существенные ограничения по гарантированию целостности данных за пределами одной ноды.
Чтобы избежать данных проблем используется два варианта моделей, обеспечивающих целостное состояние:
- CQRS – разделение операций чтения и записи на два потока
- Event sourcing – сохранения в БД не конечного состояния, а набора «событий», которые привели к этому состоянию.
Основные принципы доменного моделирования:
- мысли выражениями
- сначала абстракция, затем вычисления
- используй наиболее простую абстракцию, которая подходит
- показывай «что делать», скрывай «как делать»
- изолируй с помощью bounded context
- предпочитай future акторам
- прогнозирую на ближайшую перспективу
Вывод: книга обзорно рассматривает основные понятие связанные с функциональным программированием и DDD. Затем подробно показывает как с помощью основных инструментов SCALA реализовать DDD с помощью функционального программирования. В книге подробно рассматриваются основные паттерны и приемы функционального проектирования. Рассматриваются вопросы построения целостных моделей, вопросы тестирования. Книга требует хорошего понимания SCALA и функционального программирования, использовать книгу как учебник по SCALA не получится.
👍1
А вот это уже интересно, кажется MS окончательно отчаялся починить свои отношения с docker-nvidia и просто добавит в WSL2 возможность прямого обращения к GPU.
https://devblogs.microsoft.com/directx/directx-heart-linux/
https://devblogs.microsoft.com/directx/directx-heart-linux/
Microsoft News
DirectX ❤ Linux
DirectX 12, NVIDIA CUDA, OpenGL and OpenCL acceleration are coming to the Windows Subsystem for Linux.
Иначе как "китайским чудом" назвать TikTok я не могу, пару лет назад его оценивали в 75 млрд. долларов, а сегодня он уже переваливает за 100 млрд.
https://www.bloomberg.com/news/articles/2020-05-20/tiktok-owner-s-value-surpasses-100-billion-in-private-markets
https://www.bloomberg.com/news/articles/2020-05-20/tiktok-owner-s-value-surpasses-100-billion-in-private-markets
Bloomberg.com
TikTok Owner’s Value Exceeds $100 Billion in Private Markets
ByteDance Ltd.’s valuation has risen at least a third to more than $100 billion in recent private share transactions, people familiar with the matter said, reflecting expectations the owner of video phenom TikTok will keep pulling in advertisers.
Вот так думаешь создать репозиторий, где собрать основные алгоритмы, а он уже есть - https://github.com/TheAlgorithms
GitHub
The Algorithms
Open Source resource for learning Data Structures & Algorithms and their implementation in any Programming Language - The Algorithms
"Сначала они тебя не замечают, потом смеются над тобой, затем борются с тобой. А потом ты побеждаешь." Махатма Ганди. Похоже Microsoft все больше "заимствует" из мира GNU/Linux. На этот раз речь идет о Windows Package Manager... Что дальше?
https://www.theverge.com/2020/5/20/21264739/microsoft-windows-package-manager-preview-download
https://www.theverge.com/2020/5/20/21264739/microsoft-windows-package-manager-preview-download
The Verge
Microsoft’s new Windows Package Manager is already better than the Windows Store
Top desktop apps are already making their way to the new Windows Package Manager.
Я не фанат C&C от Electronic Arts, но меня радует новость, что они решили открыть исходные коды TiberianDawn.dll и RedAlert.dll под GPL. Пока это только намерение, но уже скоро код должен появиться в открытом доступе.
https://www.ea.com/games/command-and-conquer/command-and-conquer-remastered/news/remaster-update-modding
https://www.ea.com/games/command-and-conquer/command-and-conquer-remastered/news/remaster-update-modding
Electronic Arts Inc.
Remaster Update and Open Source / Mod Support
Get answers to your Command & Conquer Remastered Collection modding questions.
24 мая планирую провести архитектурный стрим для патронов. Это первый из серии стримов на эту тему, подробнее можно прочитать здесь - https://www.patreon.com/posts/vvedenie-v-strim-37323945
Вышла 83 версия Chrome. Мне нравится, что Google планомерно идет по пути ужесточения требований к безопасности, но при этом мне это добавляет работы, потому что в некоторых случаях "безопасность" ломает решения, которые мы используем в своих проектах.
https://www.ghacks.net/2020/05/21/chrome-83-google-starts-rollout-of-redesigned-privacy-and-security-settings/
https://www.ghacks.net/2020/05/21/chrome-83-google-starts-rollout-of-redesigned-privacy-and-security-settings/
Интересная новость про долгоиграющие аккумуляторы для электрокаров, которые могут обеспечить большое количество перезарядок. Раньше были двигатели-миллионники, теперь вот батареи. А мне все же интерекен вопрос эксплуатации электрокаров в условиях низких температур, а не количество перезарядок батареи. https://insideevs.com/news/424378/gm-million-mile-ev-battery-almost-there/
InsideEVs
GM: 1 Million Mile Electric Car Battery Is 'Almost There'
1 million miles might be possible, but probably initially only in the longest range EVs (with big batteries).
А тем временем АйтиБорода замутил крутой хакатон - https://itbeard.com//hackathones/pbh
У нас в компании для управления проектами используется GitLab, отличная альтернатива GitHub для личного пользование. Уже вышла 13-ая версия с фокусом на кибербезопасность.
https://siliconangle.com/2020/05/22/gitlab-13-rolls-new-cybersecurity-features-analytics/
https://siliconangle.com/2020/05/22/gitlab-13-rolls-new-cybersecurity-features-analytics/
SiliconANGLE
GitLab 13 rolls out with new cybersecurity features and more analytics
GitLab Inc. today launched a new round-number release of its popular code hosting platform that brings more cybersecurity features, a productivity analytics tool and better support for Kubernetes envi