Моя рекомендация - максимально избегать наследования в моделях доменов.Вы можете сталкиваться с прецедентами наследования время от времени, но, вероятно, это больше относится к деталям технической реализации, чем к UL.
Я также избегаю проектировать классификацию как структуру, поскольку она делает вашу модель менее гибкой.Структура должна отражать «фиксированные» биты, которые действительно не будут меняться, такие как Invoice
/ InvoiceItem
. тип элемента счета, по-видимому, подходит для классификации.Эти вещи сложно обнаружить, но когда у вас взрыв класса, это может быть красный флаг.Как только специалисты по доменам начинают разбивать понятия на «типы», вы, вероятно, рассматриваете классификационную структуру сорта.
Кроме того, избегайте внедрения сервисов в объекты домена.Вы можете выбрать double-dispatch , когда служба, реализующая интерфейс службы, вводится в соответствующий метод, и метод вызывает службу для получения, скажем, соответствующего налога.Другой способ, который я предпочитаю, это скорее передать значения, требуемые методом.
Имейте в виду, что будут технические детали реализации, которые не собираютсябыть частью UL, так что не беспокойтесь о том, чтобы каждая часть UL была представлена как класс.Если у вас есть поведение объекта и форма UL, записанные в той или иной форме, и UL может быть полностью представлен, у вас не должно быть никаких проблем.