Изменяемая. Архитектура не может быть сформирована окончательно, какие бы паттерны ты там не применял. Требования меняются, код вместе с ними. Лучше всего тот код, который легко поддается изменениям.
Ну это звучит как девиз)
Так какой держать архитектуру. Чтобы она подавилась этим изменениям. На что должен быть разбит проект или что и где должно лежать.
При любой структуре файлов, архитектура должна биться на слои, что бы например use cases нечего не знали о request вот уже расслоение, подключение видов, уже расслоение, дальше DTO, ValueObject, Model и так далее, понятно если меняется структура данных за этим следует изменив слоев, а что бы проще было делать это не только тебе а и другим разработчикам пишутся тесты как правильно функциональные которые сразу показывают какие слои надо менять
Тебе название архитектуры сказать? Нет такой.
Это мы не вспоминали про DDD
А что ддд?) Предвкушаю набор стереотипов.
Обсуждают сегодня