Available now! Telegram Research 2025 — the year's key insights 
S0ER
Open in Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
Show more📈 Analytical overview of Telegram channel S0ER
Channel S0ER (@softwareengineervlog) in the Russian language segment is an active participant. Currently, the community unites 10 536 subscribers, ranking 11 765 in the Technologies & Applications category and 62 121 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 10 536 subscribers.
According to the latest data from 15 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -29 over the last 30 days and by -6 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 27.28%. Within the first 24 hours after publication, content typically collects N/A% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 874 views. Within the first day, a publication typically gains 0 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 137.
- Thematic interests: Content is focused on key topics such as rbp, архитектура, callme, mov, указатель.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
Thanks to the high frequency of updates (latest data received on 16 June, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
10 536
Subscribers
-624 hours
-117 days
-2930 days
Posts Archive
10 536
Обдумываю в каких ситуациях можно и нужно прибегать к параллельным вычислениям, вот такой список причин получился:
- легко формулируются как параллельные таски - задача очевидным образом разбивается на типовые подзадачи, независимые друг от друга;
- тяжелая математика - очевидно, что лучше считать параллельно от основных задач;
- задача сводится к Map-Reduce - это доп. условие к первому пункту, тут понятно, что надо map-reduce-ом решать;
- обработка графики - очевидно, что это опять же компиляция 1-2 пункта, но по сути это целый класс хорошо изученных задач, поэтому хорошо бы их сформулировать отдельно.
Какие еще причины/случаи/задачи вам приходят в голову?
10 536
Тут нужно отметить, что с архитектурной точки зрения "единственная БД" - это не совсем техническая реализация, т.е. СУБД у вас может быть несколько, они могут быть как SQL так и NOSQL и т.д. Архитектурное представление на высоком уровне не отражает физическую реализацию, а определяет назначение компонента, его обязанности, и связи.
10 536
Есть мнение, что монолит - это реализация какого-то конкретного архитектурного стиля, некоторые даже считают, что это самостоятельный архитектурный стиль.
На самом деле монолит - это характеристика архитектуры рассматривающая возможность раздельного развертывания и характеризующая силу зацепления между компонентами архитектуры.
Монолитные приложения могут быть созданы с использованием разных архитектурных стилей, как на рисунке выше.
Основная особенность, все же, в монолите почти всегда "Data centric" подход с единственной БД и единственной связью между БД и приложением.
10 536
Эта мысль мне нравится тем, что для понимания того как лучше реализовать ту или иную часть проекта, нужно последовательно понять следующие моменты:
- какие преимущества/недостатки есть в различных вариантах решения;
- какие ограничения есть в проекте;
- для чего мы реализуем тот или иной функционал.
Рассматривать поставленные вопросы нужно снизу вверх, тем самым мы как раз и приходим к простому закону: "'Why' is more important then 'how'".
10 536
В книге "Fundamentals of Software Architecture: An Engineering" Neal Ford, Mark Richards сформулирован офигенный "закон" архитектурного взгляда на проект, он звучит так: "'Why' is more important than 'how'"
10 536
Спасибо Хауди Хо за наводку про комментарии для постов, подключил чат для обсуждений, теперь должна появиться возможность комментировать оставленные сообщения.
10 536
В чем причина разделения бизнес-логики и логики приложения в DDD?
Все дело в том, что бизнес-логика - это логика "реального" мира, на нее имеют влияние процессы, которые происходят за пределами "программы", поэтому причины и вектор развития бизнес-логики будут завязаны на "реальный мир", логика приложения же завязана исключительно на само приложение и изменение, и развитие будут происходить исключительно по внутренним причинам.
Так как темпы изменений и причины разные, то разделив логику приложения и бизнес-логику мы получим более гибкое решение, которое легче сопровождать и развивать.
Если же бизнес-логика и есть логика приложения (вырожденные случаи, когда мы разрабатываем приложение без бизнеса), то разделять их не имеет смысла.
10 536
По поводу анемичных моделей надо помнить, что у нас есть совершенно разные "логики":
- бизнес-логика, независимая от приложения
- бизнес-логика, возникающая в следствие автоматизации (по сути создания приложения)
- логика приложения (по сути обязанность приложения обеспечивать свою работу)
- обязанность получения и доступа к данным (логика работы с данными)
Анемичная модель возникает в случае когда бизнес-логика в рамках домена утекает из доменной модели в другую часть программы. Но анемичная модель не может, возникать вне рамок домена.
10 536
С DDD есть несколько нюансов, которые нужно помнить:
- DDD плохо ложится на Data Centric подход, т.е. если у вас простой CRUD+Rest вокруг него, то DDD скорее всего не нужен
- DDD не имеет смысла внедрять в маленьких приложениях, на самом деле если у вас порядка 30-40 User Stories, то это очень маленькое приложение, если начать делать его по DDD, то будет получен оверхед в виде ненужных Aggregate, Registry и Entities, куда проще использовать классический Transaction Script и сервисы.
10 536
Чек-лист для проверки DDD архитектуры:
1) Проверка дизайна
существует несколько основных элементов домена, которые могут применяться для хранения стейта и реализации поведения:
- Entity, Value Object, Aggregate должны использоваться для хранения "стейта" и реализации "поведения"
- Data transfer Object - только "стейт"
- Service, Repository - только "поведение"
2) В DDD как правило используются следующие паттерны:
- Domain Object
- DTO
- Repository
- DAO
3) В DDD по возможности не должно быть:
- Анемичных моделей
- Fat Service
- Зацепления между разными Enteties
10 536
Памятка по версионированию:
1. Наиболее распространено семантическое версионирование
MAJOR.MINOR.PATH-LABEL+MetaInfo
MAJOR - обратно несовместимые изменения
MINOR - обратно-совместимые изменения
PATCH - локальные изменения
2. Библиотеки при учете совместимости должны учитывать:
- бинарную совместимость
- семантическую совместимость (один и тот же код, должен должен приводить к одному и тому же результату)
- совместимость на уровне интерфейсов кода (один и тот же метод, должен иметь одну и ту же сигнатуру вызова)
Если хотя бы одно из условий нарушается - увеличивается MAJOR версия
3. API должны учитывать совместимость:
- по версии клиента (должен поддерживать все клиенты предыдущего API)
- по версии сервера (должен работать на серверах поддерживающих предыдущий API)
- по версии протокола (должен поддерживать все протоколы, что и предыдущий API)
Если хотя бы одно условие нарушается, увеличивается MAJOR версия.
4. Схемы данных
- При добавлении необязательных полей с дефолтным состоянием увеличивается MINOR
- При добавлении обязательных полей увеличивается MAJOR
10 536
- специализированные API - как правило API построенные на каком либо языке запросов, которые разрабатываются конкретно под сервер. Пример: SQL.
10 536
- REpresentational State Transfer (REST) - набор прицнипов для построения легковесных API, как правило использует текстовый формат для обмена сообщениями (JSON, XML). Текстовый формат сообщений позволяет развязать зависимости сервера и клиента, не использовать какие-либо общие библиотеки. Унифицирован для веб-разработки.
10 536
- Remote method invocation (RMI) - вариант RPC который "скрывает" удаленную природу вычислений и со стороны клиента выглядит так, будто вычисления выполняются локально.
10 536
API стили:
- Remote Procedure Call (RPC) - удаленный вызов процедур, один из самых используемых стилей при построении API. Он реализуется с помощью клиент-серверного шаблона архитектуры, и позволяет клиенту выполнять свой код удаленно на сервере.
Обычно используют компактные бинарные форматы. Пример: gRPC ( https://grpc.io ), из более ранних примеров - SOAP
10 536
По всем flow можно посмотреть конспект для архитектурных стримов: https://s0er.ru/codelabs/arch_stream_15/index.html#0
