DDD - Зависимости между моделью домена, сервисами и репозиториями

К вашему последнему пункту, службы в DDD - это место, где можно описать то, что я называю «неловкой» логикой. Если у вас есть какой-то тип логики или рабочий процесс, который зависит от других объектов, это тип логики, который обычно не «вписывается» в сам объект домена. Пример: если у меня есть бизнес-объект для выполнения некоторого типа проверки, класс сервиса мог бы выполнить этот метод (сохраняя при этом действительную логику проверки, связанную с сущностью внутри своего класса)

Еще один действительно хороший пример, который я всегда упоминаю метод перевода средств У вас не будет возможности переносить объект учетной записи с одного объекта на другой, но вместо этого у вас будет служба, которая использует учетную запись «to» и учетную запись «from». Затем внутри сервиса вы будете вызывать метод снятия средств со своего счета «с» и метод депозита с вашего счета «на». Если бы вы попытались поместить это внутри самой учетной записи, это было бы неловко.

Здесь можно найти отличный подкаст, подробно рассказывающий об этой теме . Дэвид Лариби делает действительно хорошую работу, объясняя теперь только «как», но «почему» DDD.

Ваша доменная модель не должна иметь ссылку ни на ProductService, ни на IProductRepository. Если вы создаете новый продукт, он должен быть создан с помощью фабрики - фабрика может использовать ProductService для получения идентификатора продукта.

Фактически, я бы обернул ProductService соответствующим интерфейсом, таким как IProductIdGeneratorService, чтобы вы могли внедрить это на завод, используя ваш контейнер IoC.

If I understand your question correctly, you state that your Product class is calling the ProductService class. It shouldn't. You should do this in a factory class that is responsible for creating and configuring a Product. Where you call this method may also depend on when you want to issue the ProductId: We have what may be a similar case in that we need to get a number from our legacy accounting system for a project. I defer getting the number until the project is persisted so that we don't waste any numbers or have gaps. If you're in a similar situation, you may want to issue the ProductId in a repository save method instead of when the object is created.

As an aside, do you really think you'll ever have more than one ProductService or ProductRepository? If not then I wouldn't bother with the interfaces.

Edited to add:

I recommend starting small and keeping it simple by starting with two just classes, Product and ProductServices. ProductServices would perform all services, including factory and repository, since you can think of those as specialized services.