S0ER

Небольшая инфографика по вариантам архитектурных решений монолитных приложений

Эта мысль мне нравится тем, что для понимания того как лучше реализовать ту или иную часть проекта, нужно последовательно понять следующие моменты:
- какие преимущества/недостатки есть в различных вариантах решения;
- какие ограничения есть в проекте;
- для чего мы реализуем тот или иной функционал.

Рассматривать поставленные вопросы нужно снизу вверх, тем самым мы как раз и приходим к простому закону: "'Why' is more important then 'how'".

В книге "Fundamentals of Software Architecture: An Engineering" Neal Ford, Mark Richards сформулирован офигенный "закон" архитектурного взгляда на проект, он звучит так: "'Why' is more important than 'how'"

Спасибо Хауди Хо за наводку про комментарии для постов, подключил чат для обсуждений, теперь должна появиться возможность комментировать оставленные сообщения.

В чем причина разделения бизнес-логики и логики приложения в DDD?
Все дело в том, что бизнес-логика - это логика "реального" мира, на нее имеют влияние процессы, которые происходят за пределами "программы", поэтому причины и вектор развития бизнес-логики будут завязаны на "реальный мир", логика приложения же завязана исключительно на само приложение и изменение, и развитие будут происходить исключительно по внутренним причинам.

Так как темпы изменений и причины разные, то разделив логику приложения и бизнес-логику мы получим более гибкое решение, которое легче сопровождать и развивать.

Если же бизнес-логика и есть логика приложения (вырожденные случаи, когда мы разрабатываем приложение без бизнеса), то разделять их не имеет смысла.

По поводу анемичных моделей надо помнить, что у нас есть совершенно разные "логики":
- бизнес-логика, независимая от приложения
- бизнес-логика, возникающая в следствие автоматизации (по сути создания приложения)
- логика приложения (по сути обязанность приложения обеспечивать свою работу)
- обязанность получения и доступа к данным (логика работы с данными)

Анемичная модель возникает в случае когда бизнес-логика в рамках домена утекает из доменной модели в другую часть программы. Но анемичная модель не может, возникать вне рамок домена.

С DDD есть несколько нюансов, которые нужно помнить:
- DDD плохо ложится на Data Centric подход, т.е. если у вас простой CRUD+Rest вокруг него, то DDD скорее всего не нужен
- DDD не имеет смысла внедрять в маленьких приложениях, на самом деле если у вас порядка 30-40 User Stories, то это очень маленькое приложение, если начать делать его по DDD, то будет получен оверхед в виде ненужных Aggregate, Registry и Entities, куда проще использовать классический Transaction Script и сервисы.

Чек-лист для проверки DDD архитектуры:
1) Проверка дизайна
существует несколько основных элементов домена, которые могут применяться для хранения стейта и реализации поведения:
- Entity, Value Object, Aggregate должны использоваться для хранения "стейта" и реализации "поведения"
- Data transfer Object - только "стейт"
- Service, Repository - только "поведение"
2) В DDD как правило используются следующие паттерны:
- Domain Object
- DTO
- Repository
- DAO
3) В DDD по возможности не должно быть:
- Анемичных моделей
- Fat Service
- Зацепления между разными Enteties

Памятка по версионированию:
1. Наиболее распространено семантическое версионирование
MAJOR.MINOR.PATH-LABEL+MetaInfo
MAJOR - обратно несовместимые изменения
MINOR - обратно-совместимые изменения
PATCH - локальные изменения
2. Библиотеки при учете совместимости должны учитывать:
- бинарную совместимость
- семантическую совместимость (один и тот же код, должен должен приводить к одному и тому же результату)
- совместимость на уровне интерфейсов кода (один и тот же метод, должен иметь одну и ту же сигнатуру вызова)
Если хотя бы одно из условий нарушается - увеличивается MAJOR версия
3. API должны учитывать совместимость:
- по версии клиента (должен поддерживать все клиенты предыдущего API)
- по версии сервера (должен работать на серверах поддерживающих предыдущий API)
- по версии протокола (должен поддерживать все протоколы, что и предыдущий API)
Если хотя бы одно условие нарушается, увеличивается MAJOR версия.
4. Схемы данных
- При добавлении необязательных полей с дефолтным состоянием увеличивается MINOR
- При добавлении обязательных полей увеличивается MAJOR

Доступ к API обычно осуществляется по следующей схеме

- специализированные API - как правило API построенные на каком либо языке запросов, которые разрабатываются конкретно под сервер. Пример: SQL.

- REpresentational State Transfer (REST) - набор прицнипов для построения легковесных API, как правило использует текстовый формат для обмена сообщениями (JSON, XML). Текстовый формат сообщений позволяет развязать зависимости сервера и клиента, не использовать какие-либо общие библиотеки. Унифицирован для веб-разработки.

- Remote method invocation (RMI) - вариант RPC который "скрывает" удаленную природу вычислений и со стороны клиента выглядит так, будто вычисления выполняются локально.

API стили:
- Remote Procedure Call (RPC) - удаленный вызов процедур, один из самых используемых стилей при построении API. Он реализуется с помощью клиент-серверного шаблона архитектуры, и позволяет клиенту выполнять свой код удаленно на сервере.
Обычно используют компактные бинарные форматы. Пример: gRPC ( https://grpc.io ), из более ранних примеров - SOAP

По всем flow можно посмотреть конспект для архитектурных стримов: https://s0er.ru/codelabs/arch_stream_15/index.html#0

Идея простая - есть одна основная ветка (trunk) весь код непрерывно сливается в нее, чтобы отсечь неработоспособные фичи (те фичи, которые находятся в разработке) используются флаги.

Таким образом мы постоянно ревьюим код через Pull Request, а фичу включаем через флаг когда она готова.

на изображении схематично показан алгоритм работы trunk flow, из плюсов:
- простой и легкий
- подходит для частых релизов и CI
- не имеет проблем "длинных" слияний (когда ветка долго в разработке находится)

Если меня попросят порекомендовать flow для разработки проекта, то пожалуй это будет Trunk based + Feature flag + Branch by abstraction

Вывод: ML - это конкретно методы обработки данных (в том числе и интеллектуальные), а DS - это общее направление, в которое входит весь спектр решения задач по обработке, хранению и визуализации данных.