Зарплата Лида .NET в Мск от 250к до 400к на руки потому что там статистика вообще по всем идиет. Включая аналитиков, тестировшиков джунов и т.д. Зря вы на эту статистику смотрите. Сеньора да, от 200к.
Хм, я таки с трудом вспомнил кто вы. Я вообще что вчера было-то не помню. Да и книги которые читал — я только в общем те выводи которые из них для себя сделал помню и все. Про вас не помню о чем мы говорили и что говорили зато помню что вы и начальник ваш — клевые чуваки. Приятные.
Ну да. Хорощий Репозиторий должен себя вести просто как какая-то коллекция. Только в реальной жизни обычно Repository это просто Порт к данным которые хранятся в БД. Такие Repository как вы говорите на практике получаются только если прям реально в памяти в массиве данные хранить а не ходить за ними в БД.
Все от контекста зависит. Конкретно тут дом Агрегат которому принадлежать полки на которых есть мука. Для простоты так описал. Если по нормальному то есть Агрегат Жилец. Есть Агрегат Дом и их связывает Сущность вроде домовая книга где есть ссылка на дом и на человека который в этом доме живет Для простого примера вполне сгодится и нет смысла так усложнять. Для данного контекста вполне норм что есть Мама->Дом->Полки->Предметы.
Маме (в качестве повара) все равно, откуда взялась мука getIngridients()
Хех, на самом деле все намного веселее будет У Мама, есть навигационное свойство Квартира — это та квартира в которой Мама живет и по сути Агрегат. Точнее у Квартира есть коллекция жильцы один из которых Мама. НУ не суть. У Квартира есть коллекция Полки у полки там коллекция Предметы. Мама сначала находит First полку на которой есть предметы и из этих предметов достает First предмет который является мукой. Ну и дальше со всем остальными ингридиентами.
DDD вообще не про геттеры и сеттеры )))) DDD оно про единый язык с бизнесом валидный в пределах ограниченного контекста. Всмысле — Яблоко из одного контектста и Яблоко из другого контекста это разные объекты с разным набором данных. Да и паттерны оттуда они тоже для того чтобы бизнесу понятно было и на его языке с ним говорить. Бизнесу например понятней если ему сказать что достаем яблоко из хранилища яблок (Repostiroy) чем — считываем используя порт адаптера данных информацию о яблоке.
Хех, вообще-то Роберт Мартин в своей Clean Architecture тоже использует Порты и Адаптеры по сути. UseCase используют OutPut Port blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Ну и судя по его картинке — Use Case это именно Application Service.
Поправьте меня если я в чем-то не прав.
Хех, можно нехило так извращаться использую паттерн Memento. Сделать у сущности все поля и свойства приватные. Делаем метод CreateMemento() который возвращает просто DTO с приватными данными сущности.
Ох уже эти предрассудки. Во многих организациях платят одинаково что фронтам что беками независимо от языка программирования. Дело вообще не в том кому больше платят. Сколько платят больше от организации конкретной зависит. Дело вообще в другом.
Эка годнота какая. Плюс вам за старания. Хотя мне больше нравилось когда автотестеры такие тысты писали. E2E aka Функциональные. Мне как разработчику хочется Unit тесты написать и дальше уже отдавать автоматам. Ну это такое, не все всегда бывает как мы того хотим.
Application Specific Logic (UseCase, ApplicationServices) это вам не Presentation и не Data Aces Layer.
Хех, на самом деле все намного веселее будет У Мама, есть навигационное свойство Квартира — это та квартира в которой Мама живет и по сути Агрегат. Точнее у Квартира есть коллекция жильцы один из которых Мама. НУ не суть. У Квартира есть коллекция Полки у полки там коллекция Предметы. Мама сначала находит First полку на которой есть предметы и из этих предметов достает First предмет который является мукой. Ну и дальше со всем остальными ингридиентами.
Ну и судя по его картинке — Use Case это именно Application Service.
Поправьте меня если я в чем-то не прав.
А с SQL в геттер это банально нарушение S из SOLID обычно.