Как приручить DDD. Часть 1. Стратегическая

[acmnu]

А можете рассказать больше про то где вы храните описания и как по ним строится код (есть ли генерация моделей, например?)

[Kesteem]

Наверное, ничего необычного тут не расскажу. Описания хранятся в confluence, у нас есть тенденция к миграции всего, что связано с разработкой, в GitLab, но те же словари UL особого смысла туда перекладывать нет. Я в своей практики не встречал удачных примеров генерации кода по неким метаданным, поэтому не рассматривал их как инструмент для своих проектов. У нас первичен код. Описания создаются силами системных аналитиков, так как мы работаем в банке, они у нас есть в качестве выделенных ролей. Если бы были только разработчики, думаю, настолько подробные описания не получилось бы реализовать

[AlexSpaizNet]

Сколько теории написано про DDD. А вот примеров имплементации ну хоть немного сложного агрегата с парочкой бизнес рулов, с 1-2 релейшенами, саб агрегатами и валуе обжектами я так и не нашел.

Я вот после написания ну очень простой имплементации рут агрегата с минимум полей и минимум агрегатов и value objects внутри, слабо представляю как все это будет работать при большой нагрузке, если не использовать магию ORM под капотом что бы загружать не весь агрегат и что бы сохранять не весь агрегат. И тут появлется соблазн использовать саму модель orm как агрегат что не есть хороше.

Имплементировать на каждый филд враппер прямо в агрегате что бы уметь определять как ой филд изменился а какой нет?

struct StatusField {

originaldata string

newdata string

isModified
}

Особенно если апишка частично crudish...
И все ради того что бы иметь один метод reservationRepo.save(reservation);

Будет интересно посмотреть на ваше решение.

[marenkov]

Здорово, что появляется все больше статей о DDD, но мне кажется, что "IMQ/Внутренняя шина данных" относиться к инфраструктуре и не должна входить в модель предметной области и единый язык. Соответственно на схеме с Card, Offers, User и Pass, вместо IMQ, я бы указал связи между ними: User 1- владеет ->* Card (у пользователя может быть любое количество карт, картой владеет ровно один пользователь).