diff --git a/README.ukrainian.md b/README.ukrainian.md
index 6c63fd135a..cc19769410 100644
--- a/README.ukrainian.md
+++ b/README.ukrainian.md
@@ -226,7 +226,7 @@ Read in a different language: [**CN**](./README.chin
**Otherwise:** When developers who code new features struggle to realize the impact of their change and fear to break other dependent components - deployments become slower and riskier. It's also considered harder to scale-out when all the business units are not separated
-🔗 [**Read More: structure by components**](./sections/projectstructre/breakintcomponents.md)
+🔗 [**Read More: structure by components**](./sections/projectstructre/breakintcomponents.ukrainian.md)
diff --git a/sections/projectstructre/breakintcomponents.ukrainian.md b/sections/projectstructre/breakintcomponents.ukrainian.md
new file mode 100644
index 0000000000..732b5f647f
--- /dev/null
+++ b/sections/projectstructre/breakintcomponents.ukrainian.md
@@ -0,0 +1,37 @@
+# Структуруйте своє рішення за компонентами
+
+
+
+### Пояснення одного абзацу
+
+Для додатків середнього розміру і вище моноліти справді погані – мати одне велике програмне забезпечення з багатьма залежностями буде складно розуміти, і це часто призводить до спагетті-коду. Навіть розумні архітектори — ті, хто достатньо вправні, щоб приборкати звіра та «модулювати» його — витрачають величезні розумові зусилля на проектування, і кожна зміна вимагає ретельної оцінки впливу на інші залежні об’єкти. Найкращим рішенням є розробка невеликого програмного забезпечення: розділіть весь стек на самодостатні компоненти, які не надають спільний доступ до файлів іншим, кожен з яких складається з небагатьох файлів (наприклад, API, сервіс, доступ до даних, тест тощо), щоб його було легко зрозуміти. Деякі можуть назвати цю архітектуру «мікросервісів» — важливо розуміти, що мікросервіси — це не специфікація, якої ви повинні дотримуватися, а радше набір принципів. Ви можете прийняти багато принципів у повноцінну архітектуру мікросервісів або прийняти лише деякі. Обидва хороші, якщо ви зберігаєте низьку складність програмного забезпечення. Щонайменше, що вам слід зробити, це створити базові межі між компонентами, призначити папку в корені вашого проекту для кожного бізнес-компонента та зробити його самостійним — іншим компонентам дозволено використовувати його функціональні можливості лише через публічний інтерфейс або API. Це основа для збереження простоти ваших компонентів, уникнення пекла залежностей і прокладання шляху до повномасштабних мікросервісів у майбутньому, коли ваша програма розшириться.
+
+
+
+### Цитата з блогу: «Масштабування вимагає масштабування всієї програми»
+
+З блогу [MartinFowler.com](https://martinfowler.com/articles/microservices.html)
+
+> Монолітні програми можуть бути успішними, але все більше людей відчувають розчарування в них, особливо тому, що все більше програм розгортається в хмарі. Цикли змін пов’язані разом – зміна, внесена до невеликої частини програми, вимагає перебудови та розгортання всього моноліту. З часом часто стає важко підтримувати хорошу модульну структуру, що ускладнює збереження змін, які мають впливати лише на один модуль у цьому модулі. Масштабування вимагає масштабування всієї програми, а не її частин, які потребують більших ресурсів.
+
+
+
+### Цитата з блогу: «То що кричить архітектура вашої програми?»
+
+З блогу [uncle-bob](https://8thlight.com/blog/uncle-bob/2011/09/30/Screaming-Architecture.html)
+
+> ...якби ви дивилися на архітектуру бібліотеки, ви б, швидше за все, побачили парадний вхід, зону для реєстраторів, зони для читання, невеликі конференц-зали та галерею за галереєю, здатні вмістити книжкові полиці для всіх книги в бібліотеці. Ця архітектура кричала б: бібліотека.
+
+Отже, про що кричить архітектура вашої програми? Коли ви дивитесь на структуру каталогів верхнього рівня та вихідні файли в пакеті найвищого рівня; вони кричать: система охорони здоров’я, чи система бухгалтерського обліку, чи система управління запасами? Або вони кричать: Rails, Spring/Hibernate або ASP?.
+
+
+
+### Добре: Структуруйте своє рішення за допомогою автономних компонентів
+
+
+
+
+
+### Погано: Згрупуйте файли за технічною роллю
+
+