Конструктор вместо монолита

Соблазн при создании платформы для сообществ — выбрать одну конкретную форму (например, ТСЖ) и сделать идеальное решение для неё. Так делает большинство существующих продуктов: одна система для домов, другая для школ, третья для коворкингов. Каждая хороша в своём, но если задача чуть отклоняется от шаблона — система не гнётся.

ComUnify выбрал противоположный путь. Не одна система под одну форму, а набор модулей, из которых сообщество собирает свою конфигурацию. Это решение требует обоснования — оно дороже в разработке, сложнее в освоении, труднее в продаже. Объясним, почему оно всё равно правильное.

Модуль — это не функция, а семейство возможностей

Большинство платформ устроены как набор функций: «есть голосование», «есть казна», «есть документы». Каждая функция — единственная и фиксированная.

В ComUnify модуль — это семейство возможностей, объединённых одной темой, с настраиваемыми параметрами. Модуль Treasury (казна) — это не «функция взаиморасчётов», а возможность: вести лицевые счета участников, проводить взаимозачёт между ними, принимать паевые взносы при вступлении и возвращать паевую долю при выходе, вводить демередж (мягкий налог на хранение для стимулирования оборота) или не вводить. Когда внутри сообщества появляются платные продукты — например, курсы или мероприятия, — Treasury участвует в учёте оплат вместе с модулем Payments и предметным модулем (Learning, Event). Один и тот же набор модулей с разными переключателями обслуживает разные сценарии.

То же справедливо для остальных модулей. Модуль Proposal (голосование) — это и общее собрание собственников, где вес голоса определяется долей в общем имуществе, и голосование совета по принципу большинства, и открытый опрос для участников клуба. Разные параметры — разное голосование, один модуль. Модуль Reputation (репутация) — это и рейтинг ремесленника по выполненным заказам, и прогресс ученика по учебной программе, и надёжность координатора проекта по выполненным обязательствам. Логика накопления везде одна, форма проявления разная.

Зачем такая абстракция

Две причины.

Первая — экономика разработки. Если бы под каждую форму сообщества делалась отдельная платформа, то на двадцать форм нужно было бы двадцать команд, двадцать кодовых баз, двадцать циклов поддержки. Это нереалистично для проекта, который начинается с одного архитектора. Модульный подход позволяет одному и тому же коду обслуживать множество сценариев — потому что отличия между ними сводятся к настройкам, не к новой логике.

Вторая — реальность сообществ. Они меняются. Маленький кооператив через два года может разрастись в зонтичную структуру. Школа, которая начинала как учебная программа, может стать живым сообществом выпускников с собственной казной. Жёсткая платформа в такой ситуации становится тормозом — нужно либо мигрировать на новую (трудно), либо растягивать старую за пределы её замысла (плохо). Модульная — просто получает новый модуль или меняет параметры существующих.

Двадцать четыре базовых модуля + пилотные

Базовое ядро движка — двадцать четыре активных модуля, объединённых по группам:

• Управление и решения: Proposal, LiquidDemocracy, Jurisdiction, Delegation, RoleManagement, Federation.
• Учёт и казна: Treasury.
• Связи между людьми: Membership, Reputation, Vouching, Mentorship, GroupDynamics.
• Разрешение споров: Arbitration, ResolutionCourt.
• Работа и координация: WorkCoordination, Workflow.
• Операции: Assembly, Documents, Registry.
• Технические: Authentication, Content, Display, Gamification, ResourcePool.

Поверх ядра — пилотные и операционные модули, разрабатываемые под конкретные задачи: Learning (учебные курсы), Event (управление мероприятиями), Payments (внутренний учёт оплат), PoolOrder (групповые заказы). Они добавлены в 2026 году и проходят пилотную обкатку. В коде на сегодня — около 28 классов модификаторов; разделение на «базовое ядро» и «пилотные» условное и со временем будет меняться.

Этот список не финальный и не священный. Несколько модулей из исходного дизайна (Staking, MarketMechanics, Challenge, MissionAlignment) были признаны несостоятельными и заархивированы — это нормальная часть исследовательского проекта.

Пресеты — упаковка для типовых случаев

Гибкость модулей с параметрами имеет цену: настройка с нуля требует понимания того, как сообщество устроено. Не каждый организатор готов вникать в детали.

Для типовых случаев предусмотрены пресеты — готовые конфигурации, в которых модули уже подобраны и параметры выставлены под конкретную форму. В платформе сейчас работают или проектируются пресеты для ТСЖ, потребительского кооператива, ремесленного объединения, учебного кружка, родительского комитета, дачного товарищества. Степень готовности у разных пресетов разная — часть доступна в интерфейсе сразу, часть требует ручной настройки модулей с консультацией. Каждый пресет в готовом виде даёт сообществу полнофункциональный набор модулей за несколько минут.

Между пресетом и индивидуальной настройкой остаётся зазор — для сообществ, которые «почти ТСЖ, но с нестандартным голосованием» или «почти кооператив, но без паевого расчёта». Этот зазор — пространство для ручной настройки, которая в проекте сейчас выглядит так: организатор сам редактирует параметры модулей, при необходимости с консультацией.

Что это даёт читателю

Из этой главы стоит запомнить три утверждения.

Первое: один движок обслуживает многие формы сообществ не потому, что он «универсальный» в маркетинговом смысле, а потому, что его модули устроены как семейства, а не как фиксированные функции.

Второе: когда в проекте говорится о новой задаче (например, «нужна образовательная платформа»), почти никогда не требуется писать новый продукт. Требуется собрать конфигурацию из существующих модулей с правильными параметрами. Иногда добавить один-два новых модуля. Это в разы дешевле, чем «начать с нуля».

Третье: модульность — это не свобода без ограничений. Пресеты задают «канонические» способы собирать сообщество, и большинство случаев должно укладываться в них. Полная свобода настройки нужна для исследовательских случаев и для нестандартных гибридов, не для каждого нового кооператива.

Следующая глава — самый прикладной модуль из всех, казна. Она показывает, как абстрактный принцип «модуль с параметрами» превращается в конкретные лицевые счета, паевые расчёты и закрытый внутренний контур.