Better Software Design

Czy da się zbudować produkcyjny system o skali prawie dwóch milionów linijek kodu, korzystając wyłącznie z agentów AI i nie pisząc kodu ręcznie? Przykład Open Mercato pokazuje, że taki kierunek jest jak najbardziej możliwy i działa w praktyce, ale wymaga fundamentalnej zmiany w podejściu do procesów SDLC.
W tym odcinku zapraszam na case study projektu Open Mercato, open-source'owego narzędzia do tworzenia rozwiązań klasy CRM/ERP, rozwijanego w duchu AI-First. Piotr Karwatka, founder i CTO Open Mercato, oraz Patryk Lewczuk, Core Developer / Forward Deployed Engineer, opowiedzą jak wygląda proces SLDC w tym projekcie oraz jakie techniki i narzędzia są do tego wykorzystywane.

Kontynuujemy mini-serię o antywzorcach Event-Driven Architecture - ponownie z Oskarem Dudyczem. Tym razem jednak bierzemy na początek na warsztat puchnące zdarzenia: jedno “uniwersalne” zdarzenie, które próbuje zadowolić wszystkich naraz. Kolejne pole, kolejne ID “na wszelki wypadek”, aż w końcu wysyłamy w świat pół swojej bazy danych.

Zupełnie jak w wierszyku o sznurku Jurka - ktoś dorzuci papierek, aż robi się góra śmieci. Jednak to tylko pretekst do tego, aby dotknąć właściwego tematu, czyli podziału między to, co publiczne, a to, co prywatne.

Zanim pójdziecie w mikroserwisy, upewnijcie się, że wasze granice są poprawne. W modularnym monolicie pomyłkę naprawicie jednym refaktorem w IDE. W rozproszonym systemie zapłacicie za to zmianami w infrastrukturze i bazach danych... Między innymi właśnie to warto zapamiętać z rozmowy z Damianem Dziaduchem, który podzielił się historią refaktoryzacji pewnego smutnego monolitu.

W poprzednim odcinku mówiliśmy o przesadnej szczegółowości eventów. Tym razem uderzamy w drugą stronę — w stronę zdarzeń-worków, które zamiast o biznesie, mówią nam tylko o tym, że "coś się w bazie zmieniło". Razem z Oskarem bierzemy na tapet CRUD-sourcing, często nazywany też obsesją stanu.

State Obsession to sytuacja, w której zamiast faktów takich jak EmailConfirmed czy PersonalDocumentVerified, Twój system wypluwa generyczne UserUpdated. Na pierwszy rzut oka wygląda to na ułatwienie, ale w praktyce to prosty przepis na wyciek szczegółów implementacyjnych i utratę intencji użytkownika.

Zapraszam na stronę https://bettersoftwaredesign.pl, gdzie znajdziesz jeszcze więcej materiałów.

Rozpoczynamy nową mini-serię, w której bierzemy na warsztat konkretne problemy ze świata Event-Driven Architecture. Razem z Oskarem Dudyczem, autorem bloga eventdriven.io postanowiliśmy przejść przez listę "antywzorców", które sprawiają, że zamiast elastycznych systemów, fundujemy sobie architektoniczną drogę przez mękę. Na pierwszy ogień idzie temat Property Sourcing.

W tym odcinku rozmawiamy z Oskarem m.in. o tym:

dlaczego interfejsy w stylu Jiry i edycja każdego pola z osobna potrafią zepsuć architekturę

jak Property Sourcing prowadzi do Event Bombardment i dlaczego twoje read modele mogą tego nie udźwignąć

czym różni się zdarzenie małe od zdarzenia "mniejszego niż powinno być"

jak wyjść z tej sytuacji obronną ręką, stosując translatory kontraktów i odpowiednie grupowanie danych