feat: add breakintcomponents.ukrainian.md

README.ukrainian.md

@@ -218,15 +218,15 @@ Read in a different language: [![CN](./assets/flags/CN.png)**CN**](./README.chin
 
 <br/><br/>
 
-# `1. Project Structure Practices`
+# `1. Практики структури проекту`
 
-## ![✔] 1.1 Structure your solution by components
+## ![✔] 1.1 Структуруйте своє рішення за компонентами
 
-**TL;DR:** The worst large applications pitfall is maintaining a huge code base with hundreds of dependencies - such a monolith slows down developers as they try to incorporate new features. Instead, partition your code into components, each gets its folder or a dedicated codebase, and ensure that each unit is kept small and simple. Visit 'Read More' below to see examples of correct project structure
+**TL;DR:** Найстрашнішою підводним каменем великих програм є підтримка величезної кодової бази із сотнями залежностей — такий моноліт уповільнює розробників, коли вони намагаються включити нові функції. Замість цього розділіть свій код на компоненти, кожен отримає свою папку або спеціальну кодову базу, і переконайтеся, що кожен блок залишається невеликим і простим. Відвідайте розділ «Детальніше» нижче, щоб побачити приклади правильної структури проекту
 
-**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)
+🔗 [**Детальніше: структура за компонентами**](./sections/projectstructre/breakintcomponents.ukrainian.md)
 
 <br/><br/>
 

sections/projectstructre/breakintcomponents.ukrainian.md

@@ -0,0 +1,37 @@
+# Структуруйте своє рішення за компонентами
+
+<br/><br/>
+
+### Пояснення одного абзацу
+
+Для додатків середнього розміру і вище моноліти справді погані – мати одне велике програмне забезпечення з багатьма залежностями буде складно розуміти, і це часто призводить до спагетті-коду. Навіть розумні архітектори — ті, хто достатньо вправні, щоб приборкати звіра та «модулювати» його — витрачають величезні розумові зусилля на проектування, і кожна зміна вимагає ретельної оцінки впливу на інші залежні об’єкти. Найкращим рішенням є розробка невеликого програмного забезпечення: розділіть весь стек на самодостатні компоненти, які не надають спільний доступ до файлів іншим, кожен з яких складається з небагатьох файлів (наприклад, API, сервіс, доступ до даних, тест тощо), щоб його було легко зрозуміти. Деякі можуть назвати цю архітектуру «мікросервісів» — важливо розуміти, що мікросервіси — це не специфікація, якої ви повинні дотримуватися, а радше набір принципів. Ви можете прийняти багато принципів у повноцінну архітектуру мікросервісів або прийняти лише деякі. Обидва хороші, якщо ви зберігаєте низьку складність програмного забезпечення. Щонайменше, що вам слід зробити, це створити базові межі між компонентами, призначити папку в корені вашого проекту для кожного бізнес-компонента та зробити його самостійним — іншим компонентам дозволено використовувати його функціональні можливості лише через публічний інтерфейс або API. Це основа для збереження простоти ваших компонентів, уникнення пекла залежностей і прокладання шляху до повномасштабних мікросервісів у майбутньому, коли ваша програма розшириться.
+
+<br/><br/>
+
+### Цитата з блогу: «Масштабування вимагає масштабування всієї програми»
+
+З блогу [MartinFowler.com](https://martinfowler.com/articles/microservices.html)
+
+> Монолітні програми можуть бути успішними, але все більше людей відчувають розчарування в них, особливо тому, що все більше програм розгортається в хмарі. Цикли змін пов’язані разом – зміна, внесена до невеликої частини програми, вимагає перебудови та розгортання всього моноліту. З часом часто стає важко підтримувати хорошу модульну структуру, що ускладнює збереження змін, які мають впливати лише на один модуль у цьому модулі. Масштабування вимагає масштабування всієї програми, а не її частин, які потребують більших ресурсів.
+
+<br/><br/>
+
+### Цитата з блогу: «То що кричить архітектура вашої програми?»
+
+З блогу [uncle-bob](https://8thlight.com/blog/uncle-bob/2011/09/30/Screaming-Architecture.html) 
+
+> ...якби ви дивилися на архітектуру бібліотеки, ви б, швидше за все, побачили парадний вхід, зону для реєстраторів, зони для читання, невеликі конференц-зали та галерею за галереєю, здатні вмістити книжкові полиці для всіх книги в бібліотеці. Ця архітектура кричала б: бібліотека.<br/>
+
+Отже, про що кричить архітектура вашої програми? Коли ви дивитесь на структуру каталогів верхнього рівня та вихідні файли в пакеті найвищого рівня; вони кричать: система охорони здоров’я, чи система бухгалтерського обліку, чи система управління запасами? Або вони кричать: Rails, Spring/Hibernate або ASP?.
+
+<br/><br/>
+
+### Добре: Структуруйте своє рішення за допомогою автономних компонентів
+
+![Структурування за компонентами](../../assets/images/structurebycomponents.PNG "Структурування за компонентами")
+
+<br/><br/>
+
+### Погано: Згрупуйте файли за технічною роллю
+
+![Структурування за технічними ролями](../../assets/images/structurebyroles.PNG "Структурування за технічними ролями")