grade

KO | EN

gitlite — search

#java #python #javascript #typescript #nextjs #docker #discord-bot #nodejs #react #ai #authentication #docker-compose

★ 60 Open GitHub ↗

Golang DDD (CQRS / Event Sourcing) Reference Application "Grade"

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Golang DDD (CQRS / Event Sourcing) Reference Application "Grade"

> 💬  "The only person whose praise matters is another programmer."
> -- "[Software Companies Die](https://homepages.uc.edu/~thomam/Articles/HowSoftwareCompaniesDie.pdf)" by Orson Scott Card

Система квалификационной классификации участников экспертных сообществ на основе хорошо зарекомендовавшего себя на практике алгоритма спортивной разрядности, где уровень мастерства спортсмена определяется уровнем мастерства других спортсменов.

## Golang DDD Framework

Общие файлы проекта были выделены в отдельный [Golang DDD Framework](https://github.com/krew-solutions/ascetic-ddd-go).

## Бизнес-требования

Бизнес-требования к системе описаны в разделе "[4.6. Система квалификационной классификации членов Организации](https://github.com/emacsway/charter/blob/main/charter.md#46-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0-%D0%BA%D0%B2%D0%B0%D0%BB%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B9-%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8-%D1%87%D0%BB%D0%B5%D0%BD%D0%BE%D0%B2-%D0%BE%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8)" Устава региональной общественной организации "Объединение ИТ-Архитекторов".

## Причины возникновения проекта

Подобные системы существуют во многих общественных объединениях.

Например, в Проектной Ассоциации:

- https://projects.management/infopage.html?Page=vision
- https://projects.management/infopage.html?Page=statuses

В LinkedIn есть система Endorsement.

Карма-движок есть в проектах:

- https://habr.com/
- https://pravoved.ru/
- https://tiqum.ru/
- https://drooble.com/
- и др.

Karma bot for Slack: https://karmabot.chat/

Репутационные движки встроены в популярные Q&A системы экспертных сообществ, например, [Biostar](https://github.com/ialbert/biostar-central/blob/a051511350871dcd82bdf0b88ce5cda9fd9ef141/biostar/accounts/models.py#L122) ([и здесь](https://github.com/ialbert/biostar-central/blob/a051511350871dcd82bdf0b88ce5cda9fd9ef141/biostar/forum/models.py#L589)) и [Askbot](https://github.com/ASKBOT/askbot-devel/blob/5f27a57069401d9eb1f7fdb57b6055d5ba2e5a5b/askbot/models/repute.py), построенных по образу [StackOverflow](https://stackoverflow.com/), в котором тоже [есть](https://stackexchange.com/leagues/1/year/stackoverflow/2023-01-01/62937) свой карма-движок.

Существует большое количество коробочных т.н. "карма-движков", например, [pinax-points](https://github.com/pinax/pinax-points), [pinax-badges](https://github.com/pinax/pinax-badges), [Telegram KarmaBot](https://github.com/bomzheg/KarmaBot).

Большую популярность набирают социальные токены.

В данном проекте предпринята попытка сделать систему максимально объективной, независимой, равноправной, прозрачной, распределенной и простой.
И одновременно с этим - максимально защищенной от фальсификаций, субъективизма и когнитивных искажений.

Ниже перечислены некоторые из причин её появления:

1. Часто приходится слышать о том, что засилье коммерциализированных сертификатов не отражает реальный уровень экспертности.  
Мы считаем, что экспертному сообществу виднее, и решили предоставить именно ему право определять уровень экспертности своих участников.  
Никто не может вмешиваться в этот процесс.  
И руководитель организации, и новичок имеют равные права рекомендовать и быть рекомендованным.

2. Еще Gregor Hohpe подсветил ключевую проблему экспертных сообществ - Эффект Даннинга-Крюгера, по причине которого генерируется большое количество информационных помех в любом экспертном сообществе, что повышает когнитивную нагрузку на участников сообщества и демотивирует грамотных экспертов.\
Система призвана восстановить качество информационного пространства.

3. Другая проблема заключается в том, что тот, кто больше всех занят делом, как правило, наиболее скромен в общении в силу дефицита времени.\
Зачастую это приводит к гегемонии бескомпетентности в информационном пространстве экспертных сообществ - от этого страдает большинство технических пабликов.

4. Закон об общественных объединениях не позволяет принимать решения по самоуправлению дифференцировано, но предусматривает возможность создания добровольных совещательных органов.\
Разные люди обладают разным уровнем экспертности, игнорирование которого не позволило бы максимально полно отразить экспертность в рекомендациях совещательного органа.

5. Большинство систем блокирования спамеров в telegram-сообществах очень примитивны и рискованы.\
Их можно усовершенствовать, если учитывать ценность вклада и уровень экспертности того, кто банит, и того, кого банят.\
Таким образом можно существенно облегчить бан спамеров и защититься от целенаправленных атак против весомых участников telegram-сообщества.

6. К экспертным сообществам нередко обращаются с запросами на консалтинг.\
Если другие компании доверяют сообществу, то сообщество должно стремиться, к тому, чтобы оправдать доверие, и предпринять конкретные шаги к тому, чтобы эти запросы были адресованы в первую очередь к тем, кто обладает наивысшим уровнем экспертности, выраженной конкретным опытом, ценность которого подтверждена другими членами организации.

7. Как reference application, мне этот проект нужен для систематизации своих собственных знаний по организации структуры кода и в качестве учебного экспоната при обучении программистов.

8. Проект призван компенсировать сложившуюся на рынке ситуацию, когда уровень зарплаты специалиста не коррелирует с реальным уровнем квалификации (Джордж Акерлоф описал эту проблему в классической статье «Рынок лимонов»).

💬 "Джордж Акерлоф в классической статье «Рынок лимонов» на примере рынка подержанных автомобилей показал, как асимметричность информации может привести к краху рынка [3].
Предположим, существует две категории подержанных автомобилей:
«лимоны» (автомобили плохого качества) и «персики» (автомобили хорошего качества). Предположим далее, что владелец каждого «лимона» готов продать его за 1000 долларов, тогда как каждый потенциальный покупатель готов заплатить за «лимон» 1500 долларов.
Допустим, владелец «персика» готов продать его за 3000 долларов, а потенциальный покупатель готов заплатить за него 4000 долларов.
**Если бы качество автомобилей было с самого начала очевидным для каждой из сторон, тогда рынок работал бы должным образом.** Все автомобили можно было бы продать: «лимоны» — по цене от 1000 до 1500 долларов, а «персики» — от 3000 до 4000 долларов.

Но что если каждый продавец знает о качестве своего автомобиля, а покупателям известно только то, что на вторичном рынке половина автомобилей — «лимоны», а другая половина — «персики»? Если бы автомобили этих двух категорий предлагались на продажу в равной пропорции, каждый покупатель был бы готов заплатить не более чем ½ × (1500 + 4000) = 2750 долларов.
Владелец, который знает, что его автомобиль относится к категории «персиков», не захочет продавать его по этой цене.
Следовательно, на рынке будут продаваться только «лимоны». Покупатели, зная об этом, будут предлагать максимум 1500 долларов.
Рынок «персиков» полностью прекратит свое существование, хотя покупатели и готовы платить за «персики», качество которых может быть доказано, вполне приемлемую для продавцов цену. Это полностью разрушает чрезмерно оптимистичную интерпретацию рынка, которая состоит в том, что рынок — это самый лучший и самый эффективный институт для ведения экономической деятельности."

[3] George A. Akerlof, “The Market for ‘Lemons’: Quality Uncertainty and the Market Mechanism,” Quarterly Journal of Economics 84, no. 3 (August 1970): 488–500.

-- "Теория игр. Искусство стратегического мышления в бизнесе и жизни" / Авинаш Диксит и Барри Нейлбафф ; пер. с англ. Н. Яцюк. — М. : Манн, Иванов и Фербер, 2015.

Обратите внимание на:

💬 "Если бы качество автомобилей было с самого начала очевидным для каждой из сторон, тогда рынок работал бы должным образом."

В этом и заключается цель данного проекта.

## Область применения проекта

Проект представляет интерес не только как демонстрационное, но еще и как вполне реально функционирующее приложение, которое, используя принципы диалектики и [теории игр](https://t.me/emacsway_log/1067), позволяет существенно повысить объективность т.н. [карма-движков](https://github.com/pinax/pinax-points), и, как результат, повысить качество информационного пространства экспертных сообществ.

Подробнее о Теории Контрактов можно посмотреть в видео "[Задача о коллективной ответственности](https://youtu.be/pjEhGZpQLn0)" / Алексей Савватеев или в книге "Теория игр: Искусство стратегического мышления в бизнесе и жизни" / Авинаш Диксит и Барри Нейлбафф ("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](https://github.com/backmeupplz/banofbot) с учетом коэффициента квалификационного класса голосующего за бан;
- и пр.

## Технические особенности

С технической стороны проект принципиально не использует ORM (чтоб продемонстрировать, как можно без него обходиться);
принципиально соблюдает ключевые принципы OOP, особенно инкапсуляцию, поскольку иначе технически невозможно гарантировать инварианты агрегатов;
использует CQRS/EventSourcing, причем, будет реализовывать Causal Consistency посредством Causal Dependencies.

Задача амбициозная. Взялся за нее потому, что не смог отыскать существующего прецедента.
Реализация сопровождается интенсивной исследовательской работой, и каждая строка кода подкреплена теоретическими изысканиями в десятках архитектурных книг.
Будет документация, ADR, архитектурная документация и трассировка требований - в общем, будет демонстрация всех SDLC-этапов разработки.

## Что можно посмотреть?

### Specification Pattern

Specification Pattern с применением Abstract [Expression Tree](https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/concepts/expression-trees/).

- [Абстрактная реализация + inMemory evaluator](https://github.com/krew-solutions/ascetic-ddd-go/tree/main/asceticddd/specification/domain)
- [Конкретная реализация inMemory evaluator без использования рефлекции](./grade/internal/domain/endorser/specifications.go)
- [Абстрактная реализация строителя PostgreSQL-запроса с учетом приоритетов операторов для исключения лишних скобочек](https://github.com/krew-solutions/ascetic-ddd-go/tree/main/asceticddd/specification/infrastructure)
- [Конкретная реализация строителя PostgreSQL-запроса с гибкой возможностью маппинга атрибутов](./grade/internal/infrastructure/repositories/endorser/endorser_specifications.go)

Заложена (но до конца не продемонстрирована) возможность просмотра коллекций сущностей внутри агрегата и поиск удовлетворения условия хотя бы одним из элементов коллекции.

Подробности см. [здесь](https://dckms.github.io/system-architecture/emacsway/it/ddd/grade/domain/specification.html).

### Aggregate Encapsulation

Использование Mediator Pattern (часто ошибочно воспринимаемый за Memento Pattern) для гарантирования инкапсуляции агрегата:

- [Endorser.Export()](./grade/internal/domain/endorser/endorser.go)

Подробности см. [здесь](https://dckms.github.io/system-architecture/emacsway/it/ddd/grade/domain/aggregate-encapsulation.html).

### Непрерывность автоинкрементальных первичных ключей внутри тенанта

Решена проблема разряженности списка автоинкрементальных первичных ключей внутри тенанта, путем [обеспечения их непрерывности](https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/sql/init.sql).

### Композитные первичные ключи

При шардировании важно попадать в нужную партицию при запросе по первичному ключу, и здесь хорошо выручают [композитные первичные ключи](https://github.com/emacsway/grade/blob/main/grade/internal/domain/member/values/member_id.go).

### Пакетирование SQL-запросов без ORM

RDBMS устроена немного по другому, нежели агрегато-(документо-)ориентированные хранилища на LSM-tree, - чем больше записей сохраняется за один коммит, тем лучше Performance.
Главное, чтоб не страдал уровень параллелизма, не возникали ожидания и взаимные блокировки.
А как сказал Nick Tune, на операциях Insert взаимные блокировки и ожидания впринципе невозможны, и такие запросы можно пакетировать, что обычно в ORM выполняет UoW.
В данном проекте [продемонстрировано, как этого можно достигнуть без ORM](https://github.com/krew-solutions/ascetic-ddd-go/tree/main/asceticddd/batch), а заодно и решить проблему N+1 при загрузке агрегатов из БД.

Подробности см. [здесь](https://dckms.github.io/system-architecture/emacsway/it/ddd/tactical-design/domain-model/domain-events/domain-events-in-ddd.html#performance).

## Документация

- [Сопроводительная методическая информация проекта](https://dckms.github.io/system-architecture/emacsway/it/ddd/grade/index.html)
- [Event Storming диаграмма](https://emacsway.github.io/grade/?view=id-1e4b38c011a5495b878e024adaed4f08)
- [CQRS Hexagonal Architecture](https://emacsway.github.io/grade/?view=id-2fb42911fd164bc989a7589e94e46abf)

## Contributing

Присоединиться к разработке: https://t.me/emacsway

## Другие похожие проекты

- [Golang DDD ES/CQRS Reference Application](https://github.com/EventStore/training-advanced-go) by EventStore contributors
- [go-iddd - showcase project for implementing DDD in Go](https://github.com/AntonStoeckl/go-iddd) by Anton Stöckl (see more info [here](https://medium.com/@TonyBologni/implementing-domain-driven-design-and-hexagonal-architecture-with-go-1-292938c0a4d4) and [here](https://medium.com/@TonyBologni/implementing-domain-driven-design-and-hexagonal-architecture-with-go-2-efd432505554>`__))
- [Complete serverless application to show how to apply DDD, Clean Architecture, and CQRS by practical refactoring of a Go project](https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-example) ([more info](https://threedots.tech/post/serverless-cloud-run-firebase-modern-go-application/)) by Robert Laszczak
- [Clean Monolith Shop](https://github.com/ThreeDotsLabs/monolith-microservice-shop) by Robert Laszczak - Source code for article "[Why using Microservices or Monolith can be just a detail?](https://threedots.tech/post/microservices-or-monolith-its-detail/)"

- [Eventhus](https://github.com/mishudark/eventhus) -- CQRS/ES toolkit for Go.
- [CQRS framework in go](https://github.com/andrewwebber/cqrs)
- [Event Horizon](https://github.com/looplab/eventhorizon) -- Event Horizon is a CQRS/ES toolkit for Go.
- [ Go Event Sourcing CQRS Microservice ](https://github.com/AleksK1NG/Go-EventSourcing-CQRS)

grade

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README