Architecture as Code or How to Survive in the Legislature and Not Go Crazy [ukr]

✍️ Talk Description:

Imagine one day your team inherits a system that was built over 4 years by six different teams — just to test hypotheses. No documentation. Just a massive monorepo and Jenkins for deployment. That’s exactly what we were handed, and that’s when we decided to take full inventory — starting with Architecture as Code.

In this talk, I’ll share how we approached architectural documentation systematically: from building C4 diagrams to creating Service Documentation, ERDs, and Sequence Diagrams. You’ll learn how we practically restored our understanding of the system, brought architectural clarity, and which tools (PlantUML, Mermaid) and methods worked best.

This talk isn't just about diagrams — it's about surviving chaos, synchronizing a team, and driving architectural evolution through transparency.

📌 Key Takeaways (bullet points):

• What a system looks like after 4 years of development by 6 undocumented teams
• The kinds of questions engineers face in such a situation — and how to structure them
• Why Architecture as Code isn't just a trend but a survival tool
• Building a C4 model: from “nothing” to understanding service responsibilities
• Service Documentation: how and why to describe languages, databases, connectors
• ERDs: why you should still diagram your DB even if you have migrations
• Sequence Diagrams as a mirror of chaos: optimizing and syncing BFFs
• Practical use of PlantUML (why we chose it) + the minimum process requirements
• Typical challenges: keeping things up to date, onboarding newcomers, handling changes

Insider tip: how one diagram can save you three backend tasks