Кратко за най-важното: Clean Architecture, Робърт С. Мартин

Това ще бъде разказ за впечатленията от книгата, както и ще бъдат разгледани някои понятия и знания, които благодарение на тази книга са били научени.

Архитектура

Можете ли, четейки тази публикация, да дадете ясен отговор на въпроса какво е архитектура? Какво представлява архитектурата в контекста на програмирането и проектирането? Каква роля играе тя? Има доста неясноти около този термин. Всичко изглежда ясно, но е някак абстрактно и без точност. Мартин смята, и аз съм съгласен с него, че приложението има две съставки:

1. Поведение (behavior) — функциите и задачите, които програмата (компонентът, услугата) изпълнява.
2. Архитектурата — този термин в голяма степен се отнася до промените в приложението.

Но дори и приложението да изпълнява много добре задачата, за която е предназначено, това изобщо не означава, че то има добра архитектура. Архитектурата не е за поведението на приложението. Архитектурата е за лекотата на променливост, архитектурата е за лекотата на внедряване, архитектурата е за независимост на разработката. Архитектурата е за скоростта, с която нов човек в екипа разбира нещата.

И ето как да изградим тази архитектура, как да се избавим от главоболията при малки промени в изискванията от PM-а или от заинтересованото лице: за това ще разкаже книгата.

За авторите

Преди да кажа нещо за тази книга, искам да кажа малко за себе си.
В момента съм Strong Junior Developer, специализиращ се в разработката на услуги чрез ASP .NET CORE.

Вече година работя в една "галерия" и изглежда, че постепенно се справям.

Тази книга я прочетох вече 2 пъти и я препоръчвам на всички:

• разработчици на вградени системи;
• фронтенд разработчици;
• бекенд разработчици;
• и дори девопс специалисти.

Всъщност на всички, които по някакъв начин са свързани с разработката на софтуер, имам предвид пряката разработка на различни приложения, без да включваме мениджърите на проекти; (въпреки че би било полезно да знаем защо разработчиците понякога прекарват два пъти повече време за задача), съветвам да прочетете тази книга.
Сега ще опитам да аргументирам защо така смятам.

Няколко думи за автора на тази книга (защото за мен авторитетът на пишещия играе голяма роля). Мисля, че ще ме разберете, макар че това не винаги е правилно, но ако авторитетен човек в сферата каже нещо — вие проявявате много повече доверие към казаното от него. Например, мисля, че ще повярвате повече на диагнозата, поставена от лекар, отколкото на диагнозата от някой от тълпата (който е търсил симптоми в интернет).

Робърт Мартин — известен като Анкъл Боб (дядо Боб) — работи в сферата на програмирането, в различни системи (от уеб услуги до вградени системи) от 1970 година. Той е технически консултант и архитект, писал е за различни технически издания, сам по себе си е много опитен програмист и човек, който е изиграл ключова роля при създаването на известните принципи SOLID (може да се каже, че е създател). Също така, искам да добавя, че тази книга ми беше препоръчана от моя тимлидер с над 15 години опит.

За книгата

Зависимости

Преди да прочета книгата, прочетох доста статии на същия Хабър, където често се появяваше думата "зависимост". Какво е това, кой от кого е зависим, какво точно означава "завися" и как един клас може да зависи от друг?

И така, по време на четенето на книгата усвоих два момента:

Зависимост — термин, значещ, че някой клас (компонент, услуга) знае за друг клас (компонент, услуга), и това знание в кода е определено (сега джавистите, шарпистите и сишниците ще ме разберат) с определен импорт на пространство от имена. С други думи: имате клас А с пространство от имена Default.Classes и клас B Another.Classes. Така, ако в сорс кода на клас А фигурира using Another.Classes; — то това означава, че клас А зависи от клас B.
За да разберете по схемата, къде е зависимият клас и къде не е — гледайте посоката на стрелката: в 1) стрелката ще сочи от клас А в посока на клас B. Това означава, че клас B е по-независим от клас А. И измененията в клас А няма да нанесат "вреда" на клас B.

SOLID

Една от основните причини, които ме накараха да прочета тази книга — е обяснението на принципите SОLID от първия източник, защото дядо Роб е разработвал тези принципи и може да се каже, че благодарение на него чуваме това наименование — SOLID.
За тези, които не са в течение — тези принципи говорят и съветват да проектирате приложенията си в съответствие с 5 правила:

S — SRP (Принцип на единичната отговорност)
O — OCP (Принцип на отвореност и затвореност)
L — LSP (Принцип на заместване на Лисков)
I — ISP (Принцип на разделяне на интерфейса)
D — DIP (Принцип на инверсия на зависимостите)

Всички тези принципи могат да бъдат приложени на ниво класове и обекти, на ниво модули и компоненти и на ниво слоеве (услуги).

Ако смятате, че Принципът на единичната отговорност означава, че клас или модул трябва да прави само едно нещо — задължително трябва да прочетете поне глава за SOLID. Защото определението, дадено по-горе — е следствие, но не и определение на самия принцип.

За Инверсия на зависимостите

Особено внимание искам да отделя на обяснението на Принципа на инверсия на зависимостите (този, който е D от SOLID). В хода на четенето на книгата осъзнавах, че това не е просто принцип, а и механизъм и инструмент, с помощта на който можете да промените посоката на вашите зависимости и да направите, например, бизнес логиката (DOMAIN) независима от детайлите на реализацията на слоя за достъп до данни (DAL).

Въпреки че самият принцип наред с останалите в SOLID означава малко не това, което е механизъм, самият механизъм се използва през цялата книга, и това е един от основните методи за инвертиране и промяна на посоката на вашите зависимости, който, между другото, се използва в DDD.

За вземане на архитектурни решения

Много често в книгата ще се споменава принципът за вземане на важни архитектурни решения: каква база данни да се използва, какъв фреймуърк да се използва, каква библиотека да включите, какво да се използва като търсачка и т.н.

Така че, авторът смята: трябва да вземате КАК МОЖЕ ПО-МАЛКО такива решения. Защото изискванията могат да се променят, ограниченията по производителността също, самата поведенческа съставка има тенденция да се променя. По време на разработката, някое решение може да изглежда по-малко ефективно от друго, по-малко удобно от друго. И силата на вашата архитектура ще определи колко бързо и безболезнено можете да замените една технология с друга (за това между другото говори OCP).

Например, изведнъж решите да използвате вместо Postgresql MongoDb, или изобщо файлове, или да използвате симулирани данни, операции с които ще се извършват в паметта. И при определени условия — това може да накара да се пренапише почти цялата логика.

За да избегнем подобни ситуации, можем да използваме някои механизми, които ще отложат максимално решението. Един от тези механизми е абстракцията.

Справки за DDD

DDD — Domain Driven Design — подход в разработката на услуги с сложна бизнес логика, критична към промените, насочен към максималното разбиране от ръководителите на проекта (PMs, търговски мениджъри и др.), заедно с обикновените участници. Тоест, целта е между всички членове на проекта да има ubiquitous language, така че всеки да може да разбере другия и да мисли в един и същ домейн с едни и същи бизнес правила.

Ако сте привърженик на DDD, или искате да бъдете такъв, или не разбирате нещо, но искате да разберете — книгата е задължителна за прочит, особено втората част.

Тук авторът обяснява за съществуването на Dependency Rule и защо, следвайки го, ще изградите правилната архитектура на приложението. Защо зависимостите трябва да се насочват към High Policy компонентите, защо домейн (High Policy компонент) трябва да бъде независим от инфраструктурата и как това ще улесни разпространението и разработката.

Абстрахиране

Чичо Роб също така разказва как детайлите на реализацията могат да навредят на системата ви и да попречат на еволюцията й без болка в бъдеще.

Помнете!
БД — това е детайл на реализацията.
Клиентите (Web, Mobile и др.) — са детайли на реализацията.
Фреймворците — са детайли на реализацията.

Необходимо е максимално да се абстрахирате от всичко това и да не зависите, използвайки описания Dependency Inversion с интерфейси и абстракции, Dependency Rule и други механизми.

Методи за изграждане на модули

Тази част ми хареса особено много, като разработчик на услуги в ASP .NET CORE. Защото тук се разглеждат методологии за изграждане на единна архитектура на услугата от готови компоненти.

Роберт описа 4 възможни схеми за разделение на слоевете.

Той подчерта защо толкова често използваният механизъм на тристепенната архитектура: UI (контролери), услуги (домейн), DAL (база данни) е доста лош в сравнение с другите. Виждал съм не много проекти, но във всеки, например микро-сервиз, на бекенда се използва именно трислойната архитектура.

Също така, доста често се използва архитектурата един-компонент-една-услуга. Като цяло и двете не са лоши, но имат доста недостатъци в сравнение, например, както се изгражда архитектура с помощта на DDD, особено при критични за промени и сложни услуги.

В общи линии, това е краят на прегледа на книгата. Самата книга ми хареса много, не съжалявам за прочетеното, благодаря на автора. На вас, скъпи читатели, благодаря за вниманието, не съдите строго — тази публикация е базирана на впечатленията от книгата и моят личен ентусиазъм.

Източник: habr.com