Разделение уровней сохраняемости и домена в приложении с расширенной моделью домена

Есть понятие, говорящее о разделении persistent layer из, чтобы сделать domain layer более надежный - он не будет зависеть от фактической реализации репозитория в persistence layer, но только в интерфейсе репозитория.

Значит, у нас есть:

      IPersonRepository {...} // in domain layer
PersonCassandraRepository implements IPersonRepository {...}  // in persistence layer
Person (Aggregate Root) {...}

А как насчет Person?

В anemic-domain-model мы можем иметь:

      IPerson {...} // in domain layer
Person implements IPerson {...} // in persistence layer

Зачем помещать Person в постоянный слой ?
Потому что он содержит код, зависящий от реализации.
Например, он может содержать аннотации, связанные с JPA, и, как и в случае с репозиторием, нам не нужна конкретная реализация хранилища данных на нашем уровне домена .

Мы можем сделать это с помощью модели anemic-domain-model , потому что Person не содержит никакой доменной логики, что означает, что мы можем поместить Person в персистентный слой .
В модели анемической предметной области данные отделены от поведения, поэтому поведение Person выполняется отдельными службами, а не записывается в самом Person.

Мы не можем сделать это разделение уровней с помощью модели rich-domain-model , потому что в этом случае Person действительно содержит логику, специфичную для предметной области.

Как бы вы сделали это разделение слоев в приложении с богатой моделью предметной области ?
А может вы думаете, что это не нужно.

Источник

2 ответа

Классы, которые сохраняются, не обязательно должны быть классами (или даже реализовывать те же интерфейсы), которые находятся в модели предметной области.

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

Ответственность репозитория при таком подходе будет заключаться в переводе между представлением на уровне постоянства и представлением Personв доменном слое.

Источник

Как бы вы сделали это разделение слоев в приложении с богатой моделью предметной области? Или, может быть, вы думаете, что это не нужно.

Это тот момент в разговоре, где устоявшаяся литература имеет тенденцию говорить: «О, черт возьми, боюсь, это все, на что у нас есть время сегодня…».

Дизайн — это то, что мы делаем, чтобы получить больше того, что мы хотим, чем мы могли бы получить, просто делая это. -- Рут Малан

Как правило, ваша бизнес-логика не заботится о деталях сантехники; бизнес-политики для транспортных контейнеров (или чего-либо еще) не зависят от того, храним ли мы информацию в файловой системе, в реляционной базе данных, в хранилище документов или в хранилище событий....

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

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

Другими словами: ненужная связь между уровнем сохраняемости и уровнем предметной области является формой технического долга , но принятие технического долга может быть правильным решением.

      IPerson {...} // in domain layer
Person implements IPerson {...} // in persistence layer

Если вы хотите «разделить» домен и постоянство, это не совсем правильно; интерфейс на самом деле не является частью уровня домена, а вместо этого является частью контракта, от которого зависит уровень домена.

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

Когда вы разделяете домен и постоянство, вы можете решить, что уровень домена будет использовать анемичную модель данных, предоставляемую постоянством, или вы можете решить, что вы просто хотите передавать информацию (значения) туда и обратно через границу. Любой из них может работать, конечно, есть разные компромиссы.

рекомендуемые

Источник
Другие вопросы по тегам