Да вряд ли бы не согласился. «Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer». В заблуждение тут может ввести термин «domain object». С доменами вообще нынче дикая путаница. Data Mapper маппит результаты запроса к источнику данных (например, БД) в объекты-сущности. Сущности эти относятся к зеленому слою (слою доступа к данным, DAL). Репозиторий хранит коллекцию этих сущностей и предоставляет упрощенные методы работы с ней (т.е. он фасад). На выход репозиторий выдает те же самые объекты «зеленых» сущностей. Интерактор (розовый слой) берет эти сущности и с помощью содержащихся в них данных инициирует объекты предметной области (желтый слой), которые, в отличии от сущностей, содержат методы обработки этих данных (т.е. правила предметной области).
Если предметной области нет, то розовый слой вполне себе может взаимодействовать сразу с «зелеными» сущностями, просто прогоняя полученные из них данные через какой-то рабочий процесс и выплевывая их наверх презентатору. Собственно, такой подход и показан на диаграмме в книге Фаулера.
Репозиторий, как впрочем и гейтвэй — это фасад/прокси к источнику данных. Его задача извлечь данные и отдать их запрашивающему. Создавать объекты предметной области — не его задача. Это не считая того, что бизнес-объект может инициироваться аккумулированными данными из запросов к разным репозиториям/гейтвэям.
Потому что это вопрос не разделения слоев (слои разделять надо), а выделения слоев. Описанный вами случай получается именно тогда, когда слои выделяют преждевременно, а не когда их в принципе разделяют. Ну а навешивание интерфейсов на все подряд — это банальное непонимание DI (который инъекция), к слоям оно имеет такое себе отношение.
Как тут не вспомнить Эйнштейна: «Всё должно быть изложено так просто, как только возможно, но не проще».
Любой CRUD как простейший пример. Вообще, что считать предметной областью — вопрос интересный. По сути это бизнес-правила из реального мира, которые, что логично, не зависят от конкретного приложения. Расчет налогов, например. Какое приложение не пиши, но бизнес-компоненты, реализующие подсчет условного НДФЛ, будут применять одну и ту же логику при калькуляции (поэтому Мартин и говорит, что Entities — это объекты, которые можно таскать за собой из приложения в приложение, если, конечно, их предметные области пересекаются). Если вся бизнес-логика — это специфичные для приложения воркфлоу и сущности, то вряд ли можно говорить о наличии предметной области и соответствующего (желтого) слоя.
Вопрос в том, должен ли зеленый слой (Репозитории) знать о желтом (Энтити). Мне кажется, Дядька Боб переборщил с использованием термина «Entity» на своей flow-диаграмме, из-за чего у вас образовалась стрелка от Repositories к Entity на последнем рисунке в разделе «Заблуждение: Слои и линейность». На мой взгляд, как раз-таки интерактор (розовый) должен лезть через гейтвэй (зеленый) в БД, получать от него DTO и с помощью них инициализировать энтити (розовый создает желтый), выполняя в них бизнес-логику в нужном порядке и реализуя таким образом юз кейс. Тогда мы получим ровно такой же флоу, как на кольцевой диаграмме, где каждый внешний слой именно что отделяет внешнего соседа от внутреннего. В более простых приложениях, в которых вообще нет никакой предметной области, слой Энтити просто будет отсутствовать как факт.
Копирование сущностей реального мира и попытка приклеить к ним потом скотчем поведение — это одна из самых распространенных ошибок ОО-дизайна. Система должна основываться на поведении, а не на структуре данных. Тем более, если это не структура данных, а структура сущностей реального мира, которая хорошо подходит для проектирования пользовательского интерфейса, но не слоя предметной области.
Подробнее про это можно почитать в главе 20 книги Роберта Мартина «Принципы, паттерны и методики гибкой разработки на языке C#» (или без языка C# в более ранней версии).
Хоть эта фраза про «любой язык» даже в предисловии упоминается, но, надо признать, примеры слишком специфичны для .NET. Особенно лирические отступления. Потому что книга Теплякова (а она хороша, спору нет) — это не обучающий материал и даже не справочник, а дискуссия на тему особенностей реализации классических паттернов на C#, что весьма ограничивает аудиторию.
Если уж речь идет о паттернах с человеческим лицом, то «человечнее» лица, чем у Фрименов, сложно придумать. Труд Банды Четырех — это все же больше справочник.
Композиция и наследование — это инструменты. Любым инструментом можно правильно пользоваться, а можно злоупотреблять, но говорить, что молоток надо предпочитать пассатижам — в корне неверно.
У компаний тоже есть некий психологический возраст. Молодые разработчики всегда находятся чуть ниже этого возраста, поэтому подходят для практически любой фирмы, но чем более компетентен (заметьте, не просто более опытен, а именно более компетентен) становится разработчик, тем больше компаний он «перерастает». От того и складывается впечатление, что рабочих мест становится меньше. В абсолютных значениях — да, но в остальном всё на своих местах. Как в крупную корпорацию не нужен мальчик на должность системного архитектора, так и начинающим сервисникам, клепающим одностраничные визитки на шаблонах с themeforest, не нужны дядьки, рассуждающие про метод подстановки Лисков.
Это неизбежность. IT-компании средних масштабов не являются таковыми с момента своего основания. Сперва это маленькие встающие на ноги конторки. Они только начинают зарабатывать деньги, экономят, нанимают молодых и перспективных (и недорогих, к слову). При условии успешного развития бизнеса однажды они (компании) все сталкиваются с ситуацией, когда качество бьет их рублем по карману, и тогда они плюют на молодых и перспективных и ищут опытных и компетентных (но дорогих). Когда качество удается выровнять, они начинают искать пути оптимизации, и нанимают молодых ПОД имеющихся опытных, чтобы вырастить экономически-выгодные кадры ровно той компетенции, которая нужна для поддержания необходимого уровня качества, обеспечивающего стабильную маржу.
Меняйте работу. Серьезно. Если в комнате вы оказались самым умным, то вам срочно надо найти другую, где люди будут умнее вас. Потому что только там смогут по достоинству оценить ваши фундаментальные знания и опыт, а вам будет, куда развиваться. И не бойтесь диалога, который автор статьи привел в самом начале. Трудовая деятельность — это взаимовыгодное сотрудничество, а не продажа себя в рабство. В данном случае не человек не подошел компании, а компания — человеку. Не та комната.
Есть люди, которым и надо сидеть 20 лет на месте Z, зная только технологию X и молча без зауми пилить проект Y. А кому не надо, идут в ту же сервисную аутсорсинговую компанию и пилят сухие микросервисы на солидной архитектуре через TDD. Мода что-то пошла всех под одну гребенку грести. Программист, пожалуй — одна из самых толерантных к возрасту профессий. Это у токаря-фрезеровщика если единственный в городе завод закрылся, то дороги две — в алкаши да в дворники. А здесь кофе налил, пошел на какой-нибудь Апворк и сиди себе никуда не спеша поддерживай легаси проекты хоть до 80-ти. С нынешним курсом пенсиям даже до индусских рейтов, как до Луны.
Мысль здесь в том, что систему определяет поведение, а не структура данных предметной области или, что еще веселее, способ хранения этих данных. В данном случае, судя по всему, говорили «ООП», а имели в виду «РСУБД». Тех же контрагентов можно было бы лепить билдером, а разницу в формировании контрактов представить стратегиями. В результате избавились бы от этого странного искусственного наследования.
Если предметной области нет, то розовый слой вполне себе может взаимодействовать сразу с «зелеными» сущностями, просто прогоняя полученные из них данные через какой-то рабочий процесс и выплевывая их наверх презентатору. Собственно, такой подход и показан на диаграмме в книге Фаулера.
Как тут не вспомнить Эйнштейна: «Всё должно быть изложено так просто, как только возможно, но не проще».
Подробнее про это можно почитать в главе 20 книги Роберта Мартина «Принципы, паттерны и методики гибкой разработки на языке C#» (или без языка C# в более ранней версии).