DDD - это не структура данных или взаимосвязь между этими структурами, а изменения, которые происходят с этими данными и границами вокруг этих изменений. DDD очень плохо объясняется во многих местах, включая курсы или конференции Pluralsight, где люди создают простое приложение, ориентированное на одного пользователя, и изо всех сил стараются навязать как можно больше принципов DDD.
Ключевым принципом в дизайне, ориентированном на предметную область, является граница. Когда вы пытаетесь найти агрегаты, сначала подумайте о процессах, которые вы выполняете в своем приложении, и о том, что вам нужно, чтобы эти процессы были согласованными. Затем создайте единую сущность, которая выполняет эти изменения, и оберните ее любыми другими необходимыми сущностями (объектами значений) в агрегате. Затем назначьте одну сущность привратником для всех процессов, которые выполняются с этими сущностями.
Начало проектирования со структуры данных - это причина номер один, по которой люди терпят неудачу в DDD. Из того, что вы предоставили, мне кажется, что ваш агрегат скорее ProjectAssignment и, возможно, Timesheet, потому что здесь, вероятно, будет лежать основная бизнес-логика. Все остальное - это лишь объекты-значения (или сущности, если вы должны использовать ORM), которые можно создать с помощью простого подхода в стиле CRUD. Существует множество дискуссий и сообщений в блогах о различиях между сущностями и объектами-значениями. Люди склонны придавать какое-то значение «объектам», которые они имеют в своей области, но для экспертов в области эти драгоценные объекты, на создание которых мы тратим так много времени, являются просто ценностями, не более того. Так что не продвигайте Client или Department как совокупный корень - это просто ценности.
Не бойтесь использовать CRUD. Многие вещи, с которыми вы сталкиваетесь при разработке своего домена, будут просто объектами ценности для экспорта домена. Они просто используют их для выполнения операций с настоящими бизнес-объектами. Их не волнует, как создается Client, как создается Department или как создается Department иерархия. Они просто создают их, а затем редактируют или удаляют. Таким образом, слова, используемые для описания Client или Department, будут просто создавать, обновлять или удалять - и эти слова очень плохие кандидаты для повсеместного языка (язык предметной области). Вездесущий язык - это очень недооцененный образец в DDD. При правильном использовании вы сэкономите массу времени, которое вы тратите на проектирование вещей, которые просто не имеют значения для бизнеса. Каждый раз, когда вы думаете, что вам нужно что-то создать или обновить - используйте CRUD! Не утруждайте себя принципами DDD, потому что они просто неприменимы, когда речь идет о таких словах, как создание или обновление.
Имейте в виду, что DDD работает только в области совместной работы и только тогда, когда у вас есть доступ к эксперту в этой области. Очень сложно одновременно иметь бизнес-эксперта и разработчика. По крайней мере, сделайте дизайн в группе или хотя бы в паре, попробуйте какой-нибудь штурм событий. По моему опыту, создание достойного DDD-дизайна само по себе почти всегда терпит неудачу.
person
berhalak
schedule
13.03.2017
