Бързо въведение в изчистената архитектура

В проект с отворен код, за който започнах да допринасям, ми беше представена концепцията за „чиста архитектура“.

Първо, беше доста поразително, но след малко четене имаше смисъл. Мислех, че би било полезно за другите, ако запиша мислите си.

Съдържание

  • Визуални изображения
  • Концепцията - представена в точки
  • Пример за код
  • Ресурси

Визуални изображения

Мисля, че винаги е добре да започнем с някаква визуализация.

Ето най-често срещаните снимки на тази концепция.

Концепцията - представена в точки

Разширено от Източник и кредит: Матиа Батистън, под CC BY 4.0

Стойността, която може да предостави

  • Ефективна стратегия за тестване, която следва тестовата пирамида
  • Рамките са изолирани в отделни модули. Когато (не ако) променим мнението си, трябва да направим промяна само на едно място. Приложението има случаи на използване, вместо да е обвързано със система CRUD
  • Крещяща архитектура, известна още като крещи предназначението си. Когато погледнете структурата на пакета, вие получавате представа за това какво прави приложението, вместо да виждате технически подробности
  • Цялата бизнес логика е в случай на употреба, така че е лесно да се намери и да не се дублира никъде другаде
  • Трудно е да се направи погрешно нещо, защото модулите налагат зависимости от компилацията. Ако се опитате да използвате нещо, което не ви е предназначено, приложението не се компилира
  • Винаги е готов за разполагане, като остави свързването на обекта за последно. Или чрез използване на флагове, така че получаваме всички предимства на непрекъснатата интеграция
  • Множество работи по истории, така че различни двойки могат лесно да работят по една и съща история едновременно, за да я завършат по-бързо
  • Добър монолит с ясни случаи на употреба, които можете да разделите на микроуслуги по-късно, след като научите повече за тях

Субекти

  • Представете вашия домейн обект
  • Прилагайте само логика, която е приложима като цяло за целия обект (напр. Валидиране на формата на име на хост)
  • Обикновени обекти: без рамки, без пояснения

Случаи на употреба

  • Представете своите бизнес действия: това е, което можете да направите с приложението. Очаквайте един случай на употреба за всяко бизнес действие
  • Чиста бизнес логика, обикновен код (с изключение може би на някои използвани библиотеки)
  • Случаят на употреба не знае кой го е задействал и как ще бъдат представени резултатите (например, може да бъде на уеб страница или - върнат като JSON, или просто регистриран и т.н.)
  • Хвърля бизнес изключения

Интерфейси / адаптери

  • Извличайте и съхранявайте данни от и към редица източници (база данни, мрежови устройства, файлова система, трети страни и т.н.)
  • Дефинирайте интерфейси за данните, от които се нуждаят, за да приложат някаква логика. Един или повече доставчици на данни ще внедрят интерфейса, но случаят на използване не знае откъде идват данните
  • Внедрете интерфейсите, дефинирани от случая на употреба
  • Има начини за взаимодействие с приложението и обикновено включват механизъм за доставка (например REST API, планирани задачи, GUI, други системи)
  • Задействайте случай на употреба и преобразувайте резултата в подходящия формат за механизма за доставка
  • контролера за MVC

Външни интерфейси

  • Използвайте каквато и да е рамка, която е най-подходяща (те така или иначе ще бъдат изолирани тук)

Пример за код

Вижте структурата на GitHub.

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

Папката Webminer е структурирана в основните слоеве:

  1. субекти
  2. случаи на употреба
  3. интерфейси_адаптери
  4. външни_интерфейси

Той трябва да отразява най-основния подход за модела на дизайна.

  • Започвайки от entities, можете да видите, че основният модел на този проект еarxiv_document
  • Следващата папка use_casesпоказва нашия случай на използване, а именно да поискаме страницата arxiv
  • След това преминаваме през interface_adaptersпапката, която предоставя адаптери за заявки за процес в REST приложение или за сериализиране
  • Последният и последният слой е external_interfaces. Това е мястото, където използваме флакон сървъра, за да реализираме функцията REST

Всички тези слоеве зависят от основните слоеве, но не и обратното.

Една важна бележка: Това не е 100% правилно внедрено в хранилището.

Защо? Защото случаите на използване всъщност са различни. В действителност основният случай на употреба е предоставянето на структурирани данни. Друг случай на употреба е да получите данните от страницата на arxiv.

Забелязахте ли тази грешка в архитектурата? Ако да, поздравления! Не само внесохте достатъчно любопитство към тази статия, но вероятно разбирате принципите достатъчно добре, за да изградите свой собствен случай и да приложите концепциите в действителност!

Съгласен ли си? Ако не, защо? Благодаря, че прочетохте статията ми! Чувствайте се свободни да оставите всякакви отзиви!

Ресурси

Ето някои статии, които намерих за полезни при разбирането на понятието „чиста архитектура“:

  • //8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
  • //www.codingblocks.net/podcast/clean-architecture-make-your-architecture-scream/
  • //github.com/mattia-battiston/clean-architecture-example
  • //medium.com/@tiagoflores_23976/how-choose-the-approvable-ios-architecture-mvc-mvp-mvvm-viper-or-clean-architecture-2d1e9b87d48
  • //de.slideshare.net/HimanshuDudhat1/mvp-clean-architecture
  • //softwareengineering.stackexchange.com/questions/336677/ what-is-the-difference-between-mvp-and-clean-architecture
  • //инженеринг.21buttons.com/clean-architecture-in-django-d326a4ab86a9
  • //gist.github.com/ygrenzinger/14812a56b9221c9feca0b3621518635b
  • //medium.freecodecamp.org/how-to-write-robust-apps-consistently-with-the-clean-architecture-9bdca93e17b
  • //marconijr.com/posts/clean-architecture-practice/

Даниел е LL.M. студент по бизнес право, работещ като софтуерен инженер и организатор на свързани с технологиите събития във Виена. В момента усилията му за лично обучение се фокусират върху машинното обучение.

Свързване на:

  • LinkedIn
  • Github
  • Среден
  • Twitter
  • Steemit
  • Hashnode