Кой е предложен начин за внедряване на _customRoleRepository в следните примери? Следният код се изпълнява в услугата на приложението.
var user = _userRepository.GetById(1);
var customRole = _customRoleRepository.GetById(user.CustomRoleId);
or
var user = _userRepository.GetById(1);
var customRole = _customRoleRepository.GetForUser(user);
Имайки предвид двете опции, вероятно бих избрал първата, която запазва последователността на достъпа чрез ID.
Ако е възможно, може да е за предпочитане да заредите персонализираната роля, когато зареждате потребителя, за да избегнете повторно отиване и връщане към базата данни, особено ако това е обичайна операция. Това може да се приложи като модел за четене.
Това предполага, че сте моделирали вашите агрегати правилно... :)
Мразя да го кажа, но в среда на DDD отговорът ми би бил нито едното, нито другото.
В първия ви пример хранилището на ролите може да не знае потребителския домейн, което е добре, но това означава, че приложението трябва да знае, че за да получи ролята, трябва да изтегли идентификатор от потребителя и след това да направи запитване към друго хранилище. С други думи, приложението действа като картограф между потребител и роля.
Във втория пример хранилището на ролите вече трябва да знае за потребителския домейн. Не е страхотно, но от друга страна приложението вече не трябва да знае за roleId. Така че това е добре. Класически вид компромис между двата подхода.
Но и в двата случая приложението все още се нуждае от две хранилища, за да получи информацията си. Какво се случва, когато са необходими повече отношения? Броят на хранилищата може бързо да нарасне и нещата да станат бъркотия.
При проектиране, управлявано от домейн, трябва да се опитате да мислите от гледна точка на съвкупни корени (AR) и контекст на домейн. За вашия примерен контекст потребителят е AR и ролята става дете. Така че може да имате:
var user = _userFinder.GetById(1);
var customRole = user.CustomRole;
Това скрива повечето от подробностите за внедряването от вашето приложение и ви позволява да се съсредоточите върху това, което всъщност трябва да правят обектите на вашия домейн.
И двете са еднакво валидни, в зависимост от вашите нужди. GetForUser би било добре, ако искате да се уверите, че извикващият код има валиден потребителски агрегат, преди да се опитате да извлечете ролите - въпреки че свързва customRoleRepository със знанието на потребителския агрегат, ако искате да изисквате извикващият код да има валиден Потребителски агрегат, тогава това свързване има цел.
GetByUserId е по-съвместим с GetById и има по-малко свързване, така че ако във вашия контекст няма значение да извикате GetByUserId дори ако клиентът няма валиден потребителски агрегат, това също е добре.
Ако зареждате ById, открих също, че използването на въведени обекти със стойност на идентичност може да бъде доста полезно за осигуряване на допълнително ниво на безопасност на типа - малко разговор за плюсовете и минусите тук https://stackoverflow.com/a/5377460/6720449 и тук https://groups.google.com/forum/#!topic/dddcqrs/WQ9zRtW3Gbg
