Каковы преимущества и недостатки чистой архитектуры?

Давай я тебе на пальцах объясню, что за зверь такой — Чистая Архитектура. Представь, что ты строишь дом, но не абы как, а с таким расчётом, чтобы когда через десять лет мода на окна поменяется, тебе не пришлось весь дом разбирать, а просто хуяк — и новые вставил. Вот примерно это и есть.

Что хорошего, блядь:

• Гибкость, как у гимнастки. Вся твоя главная логика, мозги приложения, сидит в центре, как царь в палатах. А всякая хуйня вроде баз данных, веб-фреймворков или кнопочек на экране — это снаружи. Захотел сменить базу данных с MySQL на какую-нибудь понтовую MongoDB? Да похуй! Меняешь только внешний слой, а царь-логика даже не чихнёт. Это, сука, критично, когда через год выясняется, что твой фреймворк — говно, а на новом все пишут.
• Тестируется на ура. Поскольку бизнес-правила от всего отвязаны, ты можешь их тестировать в полной изоляции. Не надо городить огород с поднятием целой базы данных, чтобы проверить, правильно ли считается скидка. Написал юнит-тест, запустил — и всё, пиздец. Надёжность зашкаливает.
• Растёт без боли. Чёткие слои — это как отделы в офисе. Одни ребята ковыряются в логике заказов, другие — рисуют кнопки, третьи — с базой работают. Можно всем параллельно пилить фичи, не мешая друг другу. Масштабируемость, ёпта!
• Поддерживать не ад. Код структурирован, всё на своих местах. Новый человек в проекте не будет неделю ходить с круглыми глазами, а быстро въедет, где что лежит. Читаемость — наше всё.

А теперь ложка дёгтя, блядь:

• Оверхеда дохуя на старте. Если ты пишешь простецкий сайтик-визитку на три страницы, то создавать кучу интерфейсов, DTO и Use Case'ов — это как из пушки по воробьям. Кода станет в разы больше, а толку для такой задачи — чуть. Это для больших и долгих проектов.
• Сложна для салаг. Чтобы это правильно применять, нужно твёрдо понимать SOLID, особенно эту самую инверсию зависимостей. Иначе вместо красоты получится каша с абстракциями, в которой и чёрт ногу сломит. Неправильно понял — сам себя и похоронил.
• Может чуть тормозить. Ну да, дополнительные слои — это дополнительные вызовы, преобразования данных. Но, честно говоря, для 99% приложений это вообще не проблема. Проблемы обычно в кривых запросах к базе или в ебанутых алгоритмах, а не в паре лишних классов.

Смотри, как это примерно выглядит в коде (на Python):

# 1. Domain Layer (Святая святых, бизнес-сущности) — нихуя не знает про внешний мир
class User:
    def __init__(self, user_id: str, name: str):
        self.user_id = user_id
        self.name = name

# 2. Application Layer (Сценарии использования, контракты) — знает только про Domain
from abc import ABC, abstractmethod

class UserRepository(ABC): # Абстрактный интерфейс, типа "обещание"
    @abstractmethod
    def save(self, user: User):
        pass

class CreateUserUseCase:
    def __init__(self, user_repo: UserRepository): # Ждём НЕ конкретную базу, а ЛЮБОЙ объект, который умеет save()
        self.user_repo = user_repo

    def execute(self, user_id: str, name: str) -> User:
        user = User(user_id, name)
        self.user_repo.save(user) # Вызываем метод по контракту
        return user

# 3. Infrastructure Layer (Реализации, доступ к данным) — знает и про Domain, и про Application
# Допустим, у нас Django
# from my_app.models import UserModel

class DjangoUserRepository(UserRepository): # Реализуем тот самый контракт
    def save(self, user: User):
        # Вот здесь уже лезем в конкретную ORM
        # UserModel.objects.create(id=user.user_id, name=user.name)
        print(f"[Имитация БД] Сохраняю пользователя {user.name} (ID: {user.user_id})")

# 4. Presentation Layer (Веб-морда, API) — тут всё собирается в кучу
# from fastapi import FastAPI
# app = FastAPI()

# @app.post("/users/")
# def create_user(user_id: str, name: str):
#     repo = DjangoUserRepository() # Подсовываем конкретную реализацию
#     use_case = CreateUserUseCase(repo) # Отдаём её Use Case'у
#     user = use_case.execute(user_id, name)
#     return {"message": f"Юзер {user.name} создан, иди нахуй."}

Короче, суть в чём: внутренние круги не должны нихуя знать про внешние. Всё взаимодействие идёт через интерфейсы (абстрактные классы). Хочешь поменять базу — пишешь новую реализацию того же интерфейса и подсовываешь её. Вся основная логика даже не заметит подмены. Красота, ёпта! Но, повторюсь, для пет-проекта из пяти файлов — это оверкилл, чих-пых тебя в сраку.