Telegram Group Search
З Новим Роком
This media is not supported in your browser
VIEW IN TELEGRAM
Проблема ES та EDA, загалом, в тому що немає конкретних сформульованих життєздатних підходів до опису потоку подій як стану представлення моделі БД з кінцевою узгодженістю (eventual consistency). Тобто усі події в EDA мають бути підкріплені відповідними синхронізаційними примітивами (CRDT, VectorClocks тощо), та фактично стан поточного актора - прямим відображенням матеріалізованого представлення БД (AP або СР). Так реалізовані PersistedActors в Akka, та відповіно з EventSourcedBehaviour надається можливість синхронізувати поточні стани з використанням розподіленного сховища з СRDT узгодженістю... але фактично таким чином є два типи акторів - які використовують для збереження стану стороннє сховище в БД (CP), та відповідно кінцево узгоджене вбудоване на CRDT (AP), як то має синхронізуватись - розробники самі мають здогадатись.

Відповідні проекти реалізовані в різних біліотеках Akka Persistance / Akka Cluster / Akka Projections та не мають повноцінних прикладів інтеграції, особливо коли йде мова про обробку подій зміни станів з використанням Change Data Capture цільових БД та відповідних лічильників транзакцій, як CRDT лічильників... до того також розробники мають самі здогадатись.

Як й з DevOps'ом й Agile - показують лише частину практик, а карго культ EDA, безвідповідальність, обмеженість, наївність, разом з "вірою в магію", й невігластво чудово монетизується.
Не знаю чи було, але ось
Дуже раджу ознайомитись з Keyless CT Signing, із-за Digital Resilience Act й вимог по BOM'ам й атестації.


https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en

https://certificate.transparency.dev/
Багато матюкався шо GitPod москальський... так от

https://github.com/eclipse-theia/theia

https://try.theia-cloud.io/

* додав реакції - можна лайкнути на свій страх і ризик
2025/04/02 02:56:41
Back to Top
HTML Embed Code: