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

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

Архитектура

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

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

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

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

За авторите

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

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

Книгата вече я прочетох два пъти и я препоръчвам на всички:

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

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

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

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

За книгата

Зависимости

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

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

Зависимостта — това е термин, който означава, че един клас (компонент, услуга) знае за друг клас (компонент, услуга), и това познание на ниво код се определя (сега програмистите на Java, C# и C ще ме разберат) с определен импорт на пространство от имена. С други думи: ако имате клас А с пространство от имена 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, или изобщо файлове, или да работите с mock-нати данни, операции с които ще се извършват в паметта. И при определени условия - това може да накара да пренапишете почти цялата логика.

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

Съобщения относно DDD

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

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

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

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

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

Запомнете!
БД — това е детайл на изпълнението.
Клиентите (Web, Mobile и др.) — детайли на изпълнението.
Фреймуърците — това е детайл на изпълнението.

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

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

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

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

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

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

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

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