Задать вопрос
  • Что делать, если тест в pytest выдаёт ошибку при сравнивании одинаковых данных бд?

    Lord_of_Rings
    @Lord_of_Rings Куратор тега Python
    Northern Strider
    В @dataclass поле id объявлено с типом int, а в sample_transactions вы передаете строкой. И на будущее - код выкладывают текстом, а не скриншотами.
    Ответ написан
    2 комментария
  • Как правильно располагать абстрактные классы, имеющие разные ответственности?

    opium
    @opium
    Просто люблю качественно работать
    а кто вызывает create_new_id и to_dict/from_dict? если только реализация репозитория (файл, json), то это детали хранения, в core им делать нечего, клади рядом с реализацией. В core остаётся то, что зовёт сам use case: IRepository и генератор id, если id нужен до сохранения. Правило простое: интерфейс принадлежит тому, кто его вызывает, а не тому, кто реализует. Отдельный core в каждом слое не нужен, только лишние папки.
    Ответ написан
    6 комментариев
  • Как понять свой проект на python, построенный по принципам чистой архитектуры, начинающему?

    opium
    @opium
    Просто люблю качественно работать
    Забей на диаграмму каждого метода — бери один сценарий и трассируй его дебаггером с брейкпоинтами, смотри call stack. Для «добавить транзакцию» примерно так:
    ConsoleUI._menu_add() → TransactionService.add() → repository.save_all()
    .

    Кстати UI у тебя лезет прямо в self.service._transactions, то есть знает внутренности сервиса напрямую — вот это и есть реальное нарушение границ слоёв, а не то как называются папки.

    SOLID зубрить не надо, возьми маленький сценарий и попробуй сменить в нём JSON на SQLite. Сразу станет видно зачем нужны интерфейсы и DIP.
    Ответ написан
    6 комментариев
  • Как понять свой проект на python, построенный по принципам чистой архитектуры, начинающему?

    master_z
    @master_z
    Программист
    Я бы начал вообще с мысли, что для обучения существуют учебники и хорошие курсы. Они как раз создаются для того, чтобы новичку не приходилось самому ломать голову над тем, с чего начать и в какой последовательности изучать материал.
    Поэтому на старте я бы не пытался самостоятельно выстроить идеальный маршрут из ООП, SOLID, паттернов и архитектуры. Гораздо разумнее взять хороший учебник по Python, пройти его последовательно и параллельно писать код руками.
    А дальше уже идти от простого к сложному:
    Python → функции и процедуры → модули → классы → ООП → несколько небольших проектов → SOLID и паттерны → архитектура
    После этого уже появляется собственный опыт и реальные проблемы. Классы могут становиться слишком большими, модули — сильно зависеть друг от друга, код становится трудно менять. И тогда SOLID и архитектурные решения воспринимаются не как набор непонятных правил, а как способы решения конкретных проблем.
    При разборе больших проектов я бы тоже не пытался сразу понять всю архитектуру. Лучше взять один сценарий и проследить его выполнение
    То есть я бы строил обучение по принципу:

    сначала учимся писать → сталкиваемся с проблемой → узнаём способ её решения → применяем → понимаем, зачем он нужен.

    А не наоборот: сначала учим архитектуру, а потом пытаемся понять, какую проблему она вообще решает.
    Ответ написан
    4 комментария