Система квалификационной классификации участников экспертных сообществ на основе хорошо зарекомендовавшего себя на практике алгоритма спортивной разрядности, где уровень мастерства спортсмена определяется уровнем мастерства других спортсменов.
Бизнес-требования к системе описаны в разделе "4.6. Система квалификационной классификации членов Организации" Устава региональной общественной организации "Объединение ИТ-Архитекторов".
Подобные системы существуют во многих общественных объединениях.
Например, в Проектной Ассоциации:
- https://projects.management/infopage.html?Page=vision
- https://projects.management/infopage.html?Page=statuses
В LinkedIn есть система Endorsement.
Карма-движок есть в проектах:
Karma bot for Slack: https://karmabot.chat/
Репутационные движки встроены в популярные Q&A системы экспертных сообществ, например, Biostar (и здесь) и Askbot, построенных по образу StackOverflow, в котором тоже есть свой карма-движок.
Существует большое количество коробочных т.н. "карма-движков", например, pinax-points, pinax-badges, Telegram KarmaBot.
Большую популярность набирают социальные токены.
В данном проекте предпринята попытка сделать систему максимально объективной, независимой, равноправной, прозрачной, распределенной и простой. И одновременно с этим - максимально защищенной от фальсификаций, субъективизма и когнитивных искажений.
Ниже перечислены некоторые из причин её появления:
-
Часто приходится слышать о том, что засилье коммерциализированных сертификатов не отражает реальный уровень экспертности.
Мы считаем, что экспертному сообществу виднее, и решили предоставить именно ему право определять уровень экспертности своих участников.
Никто не может вмешиваться в этот процесс.
И руководитель организации, и новичок имеют равные права рекомендовать и быть рекомендованным. -
Еще Gregor Hohpe подсветил ключевую проблему экспертных сообществ - Эффект Даннинга-Крюгера, по причине которого генерируется большое количество информационных помех в любом экспертном сообществе, что повышает когнитивную нагрузку на участников сообщества и демотивирует грамотных экспертов.
Система призвана восстановить качество информационного пространства. -
Другая проблема заключается в том, что тот, кто больше всех занят делом, как правило, наиболее скромен в общении в силу дефицита времени.
Зачастую это приводит к гегемонии бескомпетентности в информационном пространстве экспертных сообществ - от этого страдает большинство технических пабликов. -
Закон об общественных объединениях не позволяет принимать решения по самоуправлению дифференцировано, но предусматривает возможность создания добровольных совещательных органов.
Разные люди обладают разным уровнем экспертности, игнорирование которого не позволило бы максимально полно отразить экспертность в рекомендациях совещательного органа. -
Большинство систем блокирования спамеров в telegram-сообществах очень примитивны и рискованы.
Их можно усовершенствовать, если учитывать ценность вклада и уровень экспертности того, кто банит, и того, кого банят.
Таким образом можно существенно облегчить бан спамеров и защититься от целенаправленных атак против весомых участников telegram-сообщества. -
К экспертным сообществам нередко обращаются с запросами на консалтинг.
Если другие компании доверяют сообществу, то сообщество должно стремиться, к тому, чтобы оправдать доверие, и предпринять конкретные шаги к тому, чтобы эти запросы были адресованы в первую очередь к тем, кто обладает наивысшим уровнем экспертности, выраженной конкретным опытом, ценность которого подтверждена другими членами организации. -
Как reference application, мне этот проект нужен для систематизации своих собственных знаний по организации структуры кода и в качестве учебного экспоната при обучении программистов.
Проект представляет интерес не только как демонстрационное, но еще и как вполне реально функционирующее приложение, которое, используя принципы диалектики и теории игр, позволяет существенно повысить объективность т.н. карма-движков, и, как результат, повысить качество информационного пространства экспертных сообществ.
Подробнее о Теории Контрактов можно посмотреть в видео "Задача о коллективной ответственности" / Алексей Савватеев или в книге "Теория игр: Искусство стратегического мышления в бизнесе и жизни" / Авинаш Диксит и Барри Нейлбафф ("The Art of Strategy: A Game Theorist's Guide to Success in Business and Life" by Avinash K. Dixit, Barry J. Nalebuff).
Проект также призван выступить альтернативой малополезным формально-бюрократическим grade-системам ИТ-компаний на основе матриц компетентностей, которые не способствуют развитию специалистов, а, наоборот, препятствуют, оттягивая ресурсы времени на нерелевантные аспекты в ущерб релевантным.
Самое главное - экспертные сообщества смогут себя квалифицировать и развивать без всяких тестов, эталонов, экзаменаторов и пр. ограничителей развития, установивших монополию на компетентность.
Представьте, чтоб спортивные звания присваивались бы по такому же принципу, как система тестирования на одной из фрилансерских бирж. Все, планка взята - ты мастер спорта! Венец развития.
Система спортивной разрядности хорошо зарекомендовала себя на практике именно потому, что уровень мастерства спортсмена определяется относительно известного (т.е. доказанного) уровня мастерства других спортсменов. Т.е., по сути, методом сравнительного анализа.
Изначально проект создавался для нужд региональной общественной организации "Объединение ИТ-Архитекторов". Теперь же спектр его применения просматривается гораздо шире:
- экспертные общественные объединения (голосования совещательных органов с учетом весового коэффициента квалификационного класса участника);
- grade-системы коммерческих ИТ-компаний;
- самоподдержание уровня квалификации исполнителей в ИТ-франчайзинге;
- ранжирование исполнителей на outsourcing marketplaces;
- ранжирование преподавателей образовательных платформ;
- подключение в качестве более продвинутой версии карма-движка посредством telegram-бота в экспертные telegram-сообщества;
- система бана telegram-сообщества по типу @banofbot с учетом коэффициента квалификационного класса голосующего за бан;
- и пр.
С технической стороны проект принципиально не использует ORM (чтоб продемонстрировать, как можно без него обходиться); принципиально соблюдает ключевые принципы OOP, особенно инкапсуляцию, поскольку иначе технически невозможно гарантировать инварианты агрегатов; использует CQRS/EventSourcing, причем, будет реализовывать Causal Consistency посредством Causal Dependencies.
Задача амбициозная. Взялся за нее потому, что не смог отыскать существующего прецедента. Реализация сопровождается интенсивной исследовательской работой, и каждая строка кода подкреплена теоретическими изысканиями в десятках архитектурных книг. Будет документация, ADR, архитектурная документация и трассировка требований - в общем, будет демонстрация всех SDLC-этапов разработки.
Specification Pattern с применением Abstract Expression Tree.
- Абстрактная реализация + inMemory evaluator
- Конкретная реализация inMemory evaluator без использования рефлекции
- Абстрактная реализация строителя PostgreSQL-запроса с учетом приоритетов операторов для исключения лишних скобочек
- Конкретная реализация строителя PostgreSQL-запроса с гибкой возможностью маппинга атрибутов
Заложена (но до конца не продемонстрирована) возможность просмотра коллекций сущностей внутри агрегата и поиск удовлетворения условия хотя бы одним из элементов коллекции.
Подробности см. здесь.
Использование Mediator Pattern (часто ошибочно воспринимаемый за Memento Pattern) для гарантирования инкапсуляции агрегата:
Подробности см. здесь.
Решена проблема разряженности списка автоинкрементальных первичных ключей внутри тенанта, путем обеспечения их непрерывности.
При шардировании важно попадать в нужную партицию при запросе по первичному ключу, и здесь хорошо выручают композитные первичные ключи.
RDBMS устроена немного по другому, нежели агрегато-(документо-)ориентированные хранилища на LSM-tree, - чем больше записей сохраняется за один коммит, тем лучше Performance. Главное, чтоб не страдал уровень параллелизма, не возникали ожидания и взаимные блокировки. А как сказал Nick Tune, на операциях Insert взаимные блокировки и ожидания впринципе невозможны, и такие запросы можно пакетировать, что обычно в ORM выполняет UoW. В данном проекте продемонстрировано, как этого можно достигнуть без ORM, а заодно и решить проблему N+1 при загрузке агрегатов из БД.
Подробности см. здесь.
Сопроводительная методическая информация проекта будет накапливаться здесь.
Event Storming диаграмму можно посмотреть здесь.
Присоединиться к разработке: https://t.me/emacsway
- Golang DDD ES/CQRS Reference Application by EventStore contributors
- go-iddd - showcase project for implementing DDD in Go by Anton Stöckl (see more info here and here)
- Complete serverless application to show how to apply DDD, Clean Architecture, and CQRS by practical refactoring of a Go project (more info) by Robert Laszczak
- Clean Monolith Shop by Robert Laszczak - Source code for article "Why using Microservices or Monolith can be just a detail?"
