Вставка
- Опубліковано 21 бер 2021
- Чистая архитектура предложена Дядей Бобом для кровавого энтерпрайса, однако неожиданно получила большую популярность в сообществе Android-разработчиков. Пора исправить эту несправедливость! Я расскажу о своем опыте применения чистой архтектуры в реальных проектах: с какими вопросами пришлось столкнуться и как удалось их решить. Многие из тех, кто читает книги и статьи на тему архитектуры, вдохновляются идеями, но им непонятно как все-таки раскладывать файлы по папкам и расставлять ссылки между проектами, чтобы соответствовать рекомендациям чистой архитектуры. На примере реального проекта я покажу как лучше всего это делать. Также я расскажу не только о том, как сделать классную архитектуру, но и о том, как удержать проект в рамках чистой архитектуры по мере развития проекта, какие у архитектора есть для этого инструменты.
Аудитория и уровень:
Backend разработчики, язык программирования не имеет значения. Уровень middle и выше. Доклад будет с примерами на C#, но идеи будут понятны разработчикам на любом языке.
Презентация на Я.Диске: disk.yandex.ru/i/jOQvL14Kc3y5rA
CodeFest O! o.codefest.ru/lecture/1683 - Наука та технологія
Спасибо Денису за очень важную и практически значимую тему, с которой сталкиваются по сути все архитекторы и разработчики. Если возможно, впоследствии автору выложить простой, но реально работающий демо pet-проект, для лучшего понимания архитектурой логики со стороны начинающих.
Спасибо за доклад!
Все четко и с примерами, а то обычно любят порассуждать об абстрактных кораблях, которые бороздят...
Спасибо
Очень интересный доклад.
очень круто, но где-то с середине я перестал понимать некоторые моменты)
Пример кода в студию
Мне кажется что utils противоречит чистой архитектуре если он будет расположен с боку, да он упрощает разработку и можно пихать туда общие сервисы и хелперы, но не лучше ли для чистоты всё таки работать с ооп сущностями и реализовать нужную функциональность в них, например нам нужно преобразовать строку (причём этот функционал нужен будет в нескольких компонентах) для этого мы создаём абстрактный класс строка с общим методом, а в компонентах реализуем наследников
Интересно как твоё мнение изменилось за год. Сейчас смотрю на это и у меня аналогичный вывод о том, что utils избыточен
@@Famouse продолжаю следовать чистой архитектуре по возможности, хотя в маленьких проектах и мвп это лишнее, в больших проектах в каждом отдельном модуле свои хелперы-valueobjects-utils, получается дублирование кода, но зато нет не контролируеммых зависимостей между модулями. Главное соблюдать направление зависимостей utils не могут зависить от другого кода и ничего не должны знать о другом коде, остальной код может зависить от utils, но желательно в рамках модуля.
Вообщем utils не сбоку, а ещё глубже сущностей в центре
Ну молодец, все дискуссионные вопросы просто зарешал в максимум, ладно еще хоть и упомянул что они дискуссионные ) В парадигму CQRS втащил медиатор зачем то, хотя он никакого отношения к ней не имеет, просто взял и поставил знак равенства CQRS = MediatrR. Плюсом еще намешал разные архитектурные паттерны в одну дикую солянку. Кушайте не обляпайтесь )
кто во что горазд. когда же появиться лидер рынка который унифицирует наработки и четко скажет всем как надо (то как произошло js vs react vs angular vs vue).
19:00. В очередной раз убеждаюсь что лучше книги чем слушать этот бред.
val bnk = "clearLove"