При обмене понятиями внутри модели предметной области, где существует нечто, имеющее имя и звучащее как объект, но перекрывающееся с ответственностью одного из 5 основных строительных блоков DDD, что является наилучшей практикой для именования этого объекта и / или обращенияс дизайном, который может включать или не включать это имя или фразу в фактическую реализацию?
Чтобы привести более конкретный пример, скажем, что мы разрабатываем приложение для отслеживания времени в духе DDD и сталкиваемся с чем-то, что является предметной областью.Эксперты называют «журналом времени», который должен быть журналом, в котором хранятся данные о времени входа и времени для всех сотрудников.
Исходя из этой информации, моя первоначальная мысль состоит в том, что если бы существовал класс, написанный с именем TimeLog, который позволял бы запрашивать существующие записи времени, а также сохранять новые или измененные записи журнала времени, такой класс действительно играет рольDDD хранилище.Для простоты, давайте предположим, что после различных обсуждений и рефакторинга мы пришли к выводу, что каждый раз, когда запись в журнале, по сути, является собственным агрегированным корнем и, следовательно, нуждается в соответствующем репозитории.
Теперь у нас осталосьвозможность назвать наш репозиторий как TimeLog , что кажется более соответствующим концепции DDD вездесущего языка, или мы могли бы назвать его TimeLogEntryRepository , который, кажется, соответствует более общему соглашению для именования репозиториевпосле Агрегированного корня, который они запрашивают / сохраняют.Я больше склоняюсь к идее использования TimeLog, так как он в большей степени описывает реальную роль, которую он играет в модели предметной области, что, в свою очередь, должно помочь донести информацию о дизайне до экспертов по предметной области.С другой стороны, выбор использования TimeLogEntryRepository следует существующим соглашениям DDD и, таким образом, облегчит разработку для разработчиков.Компромисс также может заключаться в использовании именования TimeLog, но в том, чтобы все репозитории реализовывали интерфейс IRepository или наследовали от общего базового класса репозитория, чтобы помочь разработчикам находить и отличать классы репозитория от других, которые составляют модель предметной области.Основная проблема, с которой я сталкиваюсь при использовании базового класса, заключается в том, что он может стимулировать использование интерфейсов маркеров или слабого ненужного базового класса только для целей организации, а не из-за поведенческих факторов.
Что является наилучшей практикойв подобных случаях?Я могу видеть, что тот же тип проблемы, возможно, происходит с сервисами, поскольку они являются еще одной частью типичных строительных блоков DDD, которые разработчики обычно называют с помощью суффикса «Сервис», такого как в SomeComplexActivityService, но для сущностей и объектов значений это действительно не проблема,Мне особенно интересно узнать, что могут сказать другие, у которых больше опыта DDD.