Немного размышлений о чистоте модели предметной области по мотивам рассылки On domain model purity от Хорикова.
Он там пишет:
To see how pure your domain model is, you need to imagine how you would design it if you didn’t have to persist any data to the database, and all you had to do is keep that data in the application memory. Then you need to compare this design to what you ended up with in your project. The difference would be the dent in domain model purity
Чтобы увидеть, насколько чиста ваша модель предметной области, вам нужно представить, как бы вы ее спроектировали, если бы вам не нужно было сохранять какие-либо данные в базе данных, а все, что вам нужно было сделать, это сохранить эти данные в памяти приложения. Затем вам нужно сравнить этот дизайн с тем, что в итоге получилось в вашем проекте. Разница между ними и будет дырой в чистоте вашей модели.
То есть Хориков полагает, что наличие БД влияет на дизайн системы.
И когда-то я думал так же. В частности, qbit был попыткой сделать такую систему хранения, которая позволила бы писать программы так, как будто все данные живут в памяти.
А сейчас я думаю, что с точки зрения дизайна у меня ничего не поменяется.
Я всё равно буду моделировать состояние системы как набор изменяемых Map неизменяемых структур данных (ака Spring Data JDBC Repository).
Возможно, у меня будет меньше специализированных под юз кейсы ДТОшек.
Совершенно точно я начну спокойно ходить по ссылкам между сущностями внутри бизнес-логики (а-ля Datomic Pull API)..
Но совершенно точно не перейду на модель огромного графа изменяемых объектов (которую, судя по всему Хориков считает идеально чистой).
При том у Хорикова в самом примере есть противоречие:
С одной стороны, он пишет:
And the difference here is the IStudentRepository interface. The domain class simply wouldn’t need to work with this interface in a setting with no database.
Но с другой стороны, в примере он использует репоз для того, чтобы обеспечить уникльность емейла студента. И вот куда он засунет поиск студента по емейлу? В
class Domain(val students: Set<Student>)?Кажется, единственное разумное место, куда можно эту проверку засунуть - StudentsRepository. Где бы он не хранил свои данные - в памяти или БД.
В общем, функциональная модель не только лучше отражает модель в голове конечного пользователя, но и лучше отражает природу информационных систем.
#functional_architecture@ergonomic_code #ddd@ergonomic_code
