¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
S0ER
Ir al canal en Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
Mostrar más📈 Análisis del canal de Telegram S0ER
El canal S0ER (@softwareengineervlog) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 10 536 suscriptores, ocupando la posición 11 765 en la categoría Tecnologías y Aplicaciones y el puesto 62 121 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 10 536 suscriptores.
Según los últimos datos del 15 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -29, y en las últimas 24 horas de -6, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 27.28%. Durante las primeras 24 horas tras publicar, el contenido suele obtener N/A% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 874 visualizaciones. En el primer día suele acumular 0 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 137.
- Intereses temáticos: El contenido se centra en temas clave como rbp, архитектура, callme, mov, указатель.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 16 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
10 536
Suscriptores
-624 horas
-117 días
-2930 días
Archivo de publicaciones
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
