Очередной ORM ушел на задворки истории:

"go-pg is in a maintenance mode and will NOT receive new features. Please use Bun Golang ORM instead."
- https://pg.uptrace.dev/

Когда спрашивают, является ли ORM слоем абстракции....

Шикарная статья для тех, кто намерен использовать PostgreSQL JSONB для хранения Агрегатов:

"Борьба с  TOAST или будущее JSONB в PostgreSQL"
- https://habr.com/ru/company/oleg-bunin/blog/646987/

Статья является продолжением статьи
"Проклятье TOAST и с каким маслом его ест JSONB" by Oleg Bartunov
- https://habr.com/ru/company/oleg-bunin/blog/597187/

Обе статьи уместны в контексте статьи "The Ideal Domain-Driven Design Aggregate Store?" by Vaughn Vernon
- https://kalele.io/the-ideal-domain-driven-design-aggregate-store/

#DDD #Database #PostgreSQL

"UUID версии 7, или как не потеряться во времени при создании идентификатора"
- https://habr.com/ru/post/572700/

Интересны комментарии статьи и ссылки в них.

Thanks to @pantafive )) Кстати, у него недавно появился тг-канал, посвященный разработке на Golang:
- https://news.1rj.ru/str/smokycode

Eric Evens в своей синей книге пишет, что, в общем-то не очень хорошо, когда Specification Pattern осведомлен об SQL

💬 "Now this design has some problems. Most important, the details of the table structure have leaked into the DOMAIN LAYER ; they should be isolated in a mapping layer that relates the domain objects to the relational tables. Implicitly duplicating that information here could hurt the modifiability and maintainability of the Invoice and Customer objects, because any change to their mappings now have to be tracked in more than one place. But this example is a simple illustration of how to keep the rule in just one place. Some object-relational mapping frameworks provide the means to express such a query in terms of the model objects and attributes, generating the actual SQL in the infrastructure layer. This would let us have our cake and eat it too."
— "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

В C# для этого есть мощный механизм Expression Tree, что значительно упрощает дело. Примеры хорошо демонстрирует Vladimir Khorikov:
- https://enterprisecraftsmanship.com/posts/specification-pattern-c-implementation/
- https://enterprisecraftsmanship.com/posts/specification-pattern-always-valid-domain-model/
- https://github.com/vkhorikov/SpecificationPattern
- https://github.com/vkhorikov/SpecPattern

В Golang дело немного усложняется отсутствием нативной поддержки Expression Tree, и поддержку этих функций приходится брать на себя.

В общем, как получилась первая итерация (пока еще не финал), можно посмотреть здесь:

Абстрактная реализация + inMemory evaluator:
- https://github.com/emacsway/grade/blob/main/grade/internal/domain/seedwork/specification/

Конкретная реализация inMemory evaluator без использования рефлекции:
- https://github.com/emacsway/grade/blob/main/grade/internal/domain/endorser/specifications.go

Абстрактная реализация строителя PostgreSQL-запроса с учетом приоритетов операторов для исключения лишних скобочек:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/specification/

Конкретная реализация строителя PostgreSQL-запроса с гибкой возможностью маппинга атрибутов:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/repositories/endorser/endorser_specifications.go

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

#DDD #SoftwareDesign

Идея экспортера, предложенная by Allen Holub:
- https://www.infoworld.com/article/2072302/more-on-getters-and-setters.html
удачно ложится на полностью искапсулированный объект построения SQL-запроса:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/repositories/recognizer/insert_query.go

#DDD #OOP #SoftwareDesign

Неплохой сайт для тех, кто погружается в Golang:
- https://golangbyexample.com/

#Golang

💬 "Sometimes, to improve performance, or more likely to tighten security, queries may be implemented on the server as stored procedures. In that case, the SPECIFICATION could carry only the parameters allowed by the stored procedure. For all that, there is no difference in the model between these various implementations. The choice of implementation is free except where specifically constrained by the model. The price comes in a more cumbersome way of writing and maintaining queries.

This discussion barely scratches the surface of the challenges of combining SPECIFICATIONS with databases, and I'll make no attempt to cover all the considerations that may arise. I just want to give a taste of the kind of choices that have to be made."
— "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

Вот так примерно отвечает интеллигентный человек на нечто подобное тому, что в свое время сделала компания LinguaLeo.

#DDD #SoftwareDesign

Все основные RFC по LDAP в одном месте:
- https://gitlab.com/samba-team/samba/-/tree/master/source4/ldap_server/devdocs
- https://pro-ldap.ru/tr/rfc/ (с переводами)
- https://ldap.com/ldap-related-rfcs/
- https://www.opennet.ru/docs/RUS/ldap_apacheds/apc/
- https://metacpan.org/dist/perl-ldap/view/lib/Net/LDAP/RFC.pod
- https://ldapwiki.com/wiki/LDAP%20Server%20Standards%20and%20Specifications

#LDAP