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