Презентація буде сфокусована на maintainability quality attribute - як зробити бізнес-логіку ізольованою, консолідованою, інкапсульованою та консистентною. А також як інтегрувати її з інфраструктурою зберігання, обміну повідомленнями, etc. Розглянемо особливості застосування таких підходів: - OOD / Rich Domain Model / DDD - Hexagonal layered architecture - CQRS/Persistance/ORM Всі особливості будуть продемонстровані на прикладі реального завдання та підходу до його реалізації (приклади коду будуть на .NET)

<p>JavaScript та Golang — це два різні світи, які часто перетинаються в сучасних проєктах: перший домінує у frontend-розробці та швидкому прототипуванні, тоді як другий — у високонавантажених сервісах та мікросервісних архітектурах. <p>У цій доповіді я поділюся власним досвідом переходу з JS на Go, порівняю підходи до асинхронного програмування, архітектури додатків, роботи з базами даних та інструментів. Ми розглянемо не тільки відмінності, а й спільні риси, які допомагають розробникам легше адаптуватися між цими екосистемами.</p>

Ця доповідь присвячена шляху розвитку після досягнення рівня сеньйор-інженера. Спираючись на власний досвід — від Junior Engineer до керівника Node.js Department — я розповім про особисті виклики, уроки та ключові моменти, які сформували мою кар’єру. Сесія стане практичним посібником для інженерів, які вже досягли рівня сеньйора і замислюються: «Що далі?». Ми розглянемо можливості як вертикального, так і горизонтального розвитку — від технічної майстерності до лідерства, від становлення експертом до формування команд і цілих департаментів.

Уявіть, що ви вирішили врятувати старий, зношений корабель, замінивши його двигуни на найсучасніші. Але замість того, щоб “полетіти у світле майбутнє”, він починає тонути ще швидше. Це історія про те, як Clean Architecture може стати і рятівним кругом, і каменем на шиї проєкту. У першій частині — хроніки болю: спроба впровадити архітектурну красу у хаос легасі коду, де навіть успіхи здавались випадковістю та чому "Ми просто робимо Clean Architecture" не завжди працює. У другій — історія “тріумфу”: коли зріла команда і правильний підхід перетворили Clean Architecture на фундамент масштабованої, гнучкої та живої системи. Дві історії з реальної практики, що показують, чому той самий підхід може як провалити, так і врятувати проєкт.

Покажу практичні підходи, типові граблі та готові шаблони, які дозволяють утримувати 200+ сервісів у продакшні і залишатися при здоровому глузді.

Запуск Diia AI всупереч усім труднощам Що потрібно, щоб створити розмовного AI-асистента для мільйонів громадян? Подорож зі створення Diia.AI, національного цифрового асистента України, почалася з простого й багатообіцяючого Proof of Concept. Але перехід від контрольної демо-версії до живої, продуктивної системи, що працює з чутливими даними та реальними державними сервісами, виявився шляхом, сповненим несподіваних викликів. Ця доповідь — чесний, закулісний погляд на нашу архітектурну еволюцію. Ми заглибимося у реальні виклики, з якими зіткнулися: від боротьби з непередбачуваними "галюцинаціями" LLM та інтеграції зі складними державними реєстрами, до проєктування системи для національного рівня безпеки й масштабування під екстремальним тиском. Це не історія бездоганного успіху; це історія вирішених проблем — від абсурдно простих до монументально складних. Приєднуйтесь, щоб дізнатися практичні уроки, яких немає в підручниках. Ми розповімо, як проєктували систему з урахуванням стійкості, застосовуючи RAG-підхід для боротьби з дезінформацією, впроваджували надійні Guardrails для забезпечення безпеки та будували масштабовану, відмовостійку екосистему. Ця сесія буде корисною для архітекторів, розробників і продуктових лідерів, які хочуть зрозуміти справжні «шрами від битв» та важко здобуті інсайти, що приходять із запуском масштабної AI-платформи всупереч усім труднощам.

Ми хотіли зробити сервіс швидким для користувачів у будь-якій точці світу. Edge Computing виглядало як ідеальне рішення. На практиці ж ми отримали і зменшення latency, і цілу купу несподіваних проблем. У цій доповіді я розповім: - як ми проектували edge-архітектуру для глобальних користувачів; - edge-провайдери та інфраструктура: що обрали і чому; - які оптимізації справді дали відчутний результат; - архітектурні компроміси, що вплинули на дизайн системи; - де edge перетворився на “edge-case” і змусив шукати нестандартні обхідні рішення; - наші факапи, та best practices;

Як проєктувати архітектуру для продукту, який уже має успішний прод, але всередині нього хочеться запускати стартапи? Як не завалити стабільну систему, зберегти довіру користувачів, і водночас дати бізнесу простір для експериментів? - Болючі кейси "важких фіч", що не прижились - Як перетворили бажання бізнесу "більше й швидше" на архітектуру - Успішний кейс швидких фіч: Таємні бокси в Expirenza - Проблеми після успіху "тимчасової" фічі - Зміна майндсету команди розробки

У багатьох проєктах хуки стали рефлексом: їх додають автоматично, навіть там, де вони не потрібні. Але кожен зайвий хук — це додаткова складність, і часто — без вигоди. У цій доповіді разом з вами спробуємо розібратися, коли хуки не потрібні та як писати простіший та зрозуміліший код без зайвих use*.

Зараз дуже багате різноманіття інструментів для документування архітектури програмного забезпечення. При цьому з часом виникає питання, а чи є інструмент, який дозволяє не тільки зображувати архітектурні блоки як взаємопов'язані сервіси чи компоненти, а й включати комплексну інформацію про бізнес-прцеси, інформаційні системи та ІТ-інфраструктуру в єдиному вигляді? Таким інстурментом є Archimate. ArchiMate — мовa моделювання для опису, візуалізації й аналізу корпоративної архітектури, що разом з TOGAF стає потужним інструментом в руках архітектора. Під час доповіді розповім на прикладах про мову моделювання Archimate, покажу які є можливості в Archi для прискорення документування та аналізу архітектури, розповім як ми в використовуємо можливості мови моделювання у нас в компанії.