Помощь в архитектурном анализе для нового проекта

Чтобы противостоять излишней академичности во всем этом и слишком долго застревать в анализе: сначала заставьте это работать. Тогда сделай красиво.

Поместите поведение как можно ближе к данным. Используйте службы, в которых вы не можете четко назначить ответственность классу (например, должен ли метод «перевода денег» быть в классе SavingsAccount?). Услуги могут быть частью агрегата.

Используйте репозитории (я не согласен с Айенде). Вы упоминаете об использовании отдельного сервисного слоя для записи в БД. Репозиторий — идеальный интерфейс, чтобы оставить этот слой позади. Это также идеальный шов для тестирования.

Не внимательно изучил вашу диаграмму классов, но вы можете злоупотреблять наследованием здесь и там. Предпочтите композицию наследованию. Наследование может довольно быстро поднять свою уродливую голову.

При выборе агрегатных корней важным критерием является жизненный цикл. Когда совокупный корень умирает, умирает и все остальное в совокупности. Совокупный корень также находится под контролем, через него проходит все, что находится за пределами совокупности. Если вы сомневаетесь, просто создайте их много (агрегат из одной сущности). В базе данных документов вы обычно храните документ для каждого агрегата, так что это в некоторой степени соответствует тому, как вы их выбираете. Храните идентификаторы ссылок на разные агрегаты.

Так что да, погружение в кроличью нору не повысит вашу производительность в краткосрочной перспективе, но может помочь вам стать разработчиком в долгосрочной перспективе. Существует так много DDD, NoSQL и т. д., что вы могли бы потратить годы только на изучение.

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

Во-первых, позвольте поздравить вас с решением предпринять шаги, чтобы попытаться стать более профессиональным. Я отчаиваюсь из-за отсутствия профессии в этой отрасли и иногда чувствую, что иду среди 80% ковбоев/хакеров и 20% профессионалов.

На ваш вопрос:

• Вы читали эту статью Вона Верона? Если нет, вы должны. Он представляет собой отличное руководство по проектированию агрегатов, которое, как мне кажется, недооценивают из-за его сложности.
• Глядя на вашу модель, я не уверен, действительно ли вы определили агрегаты? Я вижу, что вы определили корни агрегации, но агрегации должны иметь четкие границы и быть отделены от других агрегаций (т. е. не иметь объектов, ссылающихся на другие агрегированные корни, пусть они ссылаются на свой идентификатор). Имя свойства RefereeUserIDList намекает на то, что вы на самом деле это делаете, но на диаграмме показано, что оно содержит ссылку на реальный корень агрегата User?
• С точки зрения определения агрегатов и корней и дизайна модели, я не думаю, что мы можем помочь вам здесь, поскольку это полностью косвенно связано с поведенческими требованиями. Однако я скажу: старайтесь основывать свой дизайн на поведении, а не на структуре данных. Трудно изменить образ мышления, но постарайтесь не представлять себе структуру базы данных.
• Я не читал, что Айенде сказал о репозиториях, но пока вы можете издеваться над Raven API (что, я полагаю, вы можете, учитывая, что он делал моки Rhino), это не должно быть проблемой.
• Возможно, самое главное, не размещайте всю логику вашего домена на уровне сервиса. Вы получите анемическую доменную модель, которая в DDD эквивалентна антихристу. .
• Лично я, изучая DDD, понимал все принципы, но с трудом пытался применить теорию на практике. Если честно, я бы сказал, что действительно добился успеха с ним только после того, как понял принципы CQRS, что дополняет DDD. Я очень рекомендую посмотреть несколько видеороликов на эту тему от Грега Янга.