S0ER

Есть мнение, что монолит - это реализация какого-то конкретного архитектурного стиля, некоторые даже считают, что это самостоятельный архитектурный стиль. На самом деле монолит - это характеристика архитектуры рассматривающая возможность раздельного развертывания и характеризующая силу зацепления между компонентами архитектуры. Монолитные приложения могут быть созданы с использованием разных архитектурных стилей, как на рисунке выше. Основная особенность, все же, в монолите почти всегда "Data centric" подход с единственной БД и единственной связью между БД и приложением.

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

Эта мысль мне нравится тем, что для понимания того как лучше реализовать ту или иную часть проекта, нужно последовательно понять следующие моменты: - какие преимущества/недостатки есть в различных вариантах решения; - какие ограничения есть в проекте; - для чего мы реализуем тот или иной функционал. Рассматривать поставленные вопросы нужно снизу вверх, тем самым мы как раз и приходим к простому закону: "'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