Собрался я, значит, написать какое-нибудь приложение. И чтобы в одном

слое были интерфейсы, в другом реализация этих интерфейсов и доступ к бд, а в третьем контроллеры

и всё было хорошо, уже собирался писать, но тут гугл мне рассказал, что в одном интерфейсе описывать все методы работы с сущностью уже не модно и надо делать типа юзкейсы. Якобы буковка I в SOLID говорит, что надо делать дофигища мелких интерфейсов, вместо одного побольше

Че, эта херня реально важная или можно забить?

а если почитать ещё, то уже можно и без контроллеров

На самом деле сами слои уже давно херня не важная ) Да и интерфейсы писать на каждый чих не нужно. Так что ваш вопрос не совсем корректен, вы сначала раскажите что вы хотите от всего этого )

хочу приложение, которое в дальнейшем будет не больно развивать и поддерживать команде из ~20 человек. И желательно без кучи оопшного бойлерплейта. Но если он помогает, но ладно)

Ну так и пишите, зачем вам слои и интерфейсы? контроллеров и ef достаточно для простых задач, а сложные нужно декомпозировать по ддд, и там у вас интерфейсы сами сложатся как нужно, если конечно правильно построите общий язык )

ну какой-то у вас мир черно-белый) у меня вот есть печальный опыт с мешаниной всего и вся в контроллерах, но и ддд как будто избыточен для проекта) что тогда делать? 😄

Перестать плакать и начать писать)) потом рефакторить

Просто вы делаете классическую ошибку принимая для себя то что если ддд, то он везде должен быть, это не так, он должен быть только где он уместен

Ну примерно так да )) Отличный совет )

я работаю в айти меньше года, но самое главное, что успел усвоить, так это то, что если тебе дали задачу срубить дерево за неделю, то 6 дней нужно потратить на заточку топора)

Ну таких молодцов мы обычно увольняем ))

😂

Исполнитель должен достаточно шустро что то вывалить, на суд, если он сидит и топоры точит, то к нему будут большие вопросы )) Даже если он вывалит что то неудобоваримое ничего страшного, поправим переделает, а сидеть молча без какого либо результата никто не даст )

это какая-то мега прилага будет? тогда сначала пишется прототип, который потом обязательно идёт в мусорку, и на основе этого опыта уже громоздячится архитектура. А если это просто один из микросервисов то в самом деле садишься и пишешь.

если задача звучит как "шустро навалить кучку кода", то пожалуйста, держите, хоть сейчас) У Артемия Лебедева когда-то давно выходила заметка про "метод прогрессивного джипега", когда у тебя в любой момент времени задача выполнена и делает то, что от неё просят, но без деталей и где-то криво-косо Так вот, если такое криво-косо показываешь, то менеджер обычно говорит "ну всё, ты же задачу сделал, вот тебе другая, делай теперь её". А по факту, из-за того, что задача решена на коленке и не готова для того, чтобы увидеть мир, получилось, что сам под свою же жопу мину положил и ждешь когда же она взорвется)

а так, подход хороший и оправданный. Вдруг резко заказчик захотел посмотреть приложение на месяц раньше) и такое бывает, поэтому поинт про шустро понятен)

Во первых Артемий не программист ) В вторых, тут большая разница от того кто над вами, вы как я понял рядовой прогер, над вами должен быть не менеджер а тимлид по сути, и тимлид уже вас затр..ет на тему допилить сучья и доободрать кору )) С менеджерами немного все по другому, и тут скорее нужны уже софт скилы другие и мышление иное немного )

такое обычно делают в начале создания проекта когда нужна MVP

ну вот нет у нас щяс ни тимлида, никого) есть я, потсоны и манагеры)

Я вам больше того скажу, нормальные заказчики опытные, прекрасно знают то что прогеры обязательно сделают все не так, так как тут не поняли, тут поняли неправильно, здесь допридумывали, и прочее, поэтому контролят все и как можно раньше чтобы потом время не терять на переделку большей кучи )

Так садитесь и пишите, и пишите так чтобы результат был как можно раньше, используйте самые простые средства что знаете, а потом если это будет надо отрефакторите )

спешка ни к чему в моем случае. Но спасибо за совет)

Зря вы так, чем раньше покажете результат, тем раньше вам объяснять что вы ВСЕ сделали не так, и тем больше останется времени сделать все как надо )