А с DDD кто то уже работал?
Какие впечатления? А то реклама красивая, но про недостатки не кричат.
Угу, работал. Основной недостаток (имхо) - надо промывать мозги разработчикам. Сдвиг парадигм.
Как и во всем, что в сторону микросервисов смотрит - да, у нас будет встречаться одинаковый код. Да, Value Type-ы кажутся перебором (но как же с ними потом удобно). Да, хибернейт надо импользовать аккуратно (а лучше вообще не).
А так - хорошо продуманная технология как можно разрабатывать сервисы (незаметно для санитаров) и реже сраться с заказчиками :)
P.S. У меня даже сертификат есть - архитектура DDD. Но последние 3 года близко ничем подобным не занимался...
Прикольная парадигма. Херим половину прежних наработок и инструментов ради нишевой выгоды, которую ещё доказать на практике надо. И не забудьте прикупить пачку наших патентованных коучей по этой парадигме, а то у вас ничего не выйдет.
ну здорово, а то как раз решают пользовать или нет.
А event storming точно по AB делали на стене или онлайн, сами или приглашали модератора?
Только вот начал разбираться, что решат еще неизвестно, но вопросов море.
На стене. Онлайн тяжелее, больше аремени уходит.
На первый раз без модератора не обойдётесь. Мы первые раза... три по-моему приглашали. Потом уже втянулись и сами. Как со скрамом, где story telling, тоже привыкнуть надо и посмотреть пару раз как оно работает.
Начал играться с демо проектом дома. Что то не могу пока найти точный ответ.
Есть к нас агрегаты. Один агрегат к другому может связываться через ИД. Агрегаты мапятся на базу.
Допустим, имеем агрегаты Person (Id) и связанный Order(через PersonId).
Собственно в базе две таблицы Person с PK Id и Order с полем PersonId
В примерах, что встречал, для PersonId не делают FK. Но разве целостность базы нас не интересует?
Как же будет правильно, "соединять" таблицы или нет в ДДД?
В DDD на это ответа нет. Как удобнее. А если ещё и про NoSQL не забывать, то оно и понятно.
Тут придётся подумать про транзакции. Каждый агрегат читается и пишется своим репозиторием. Мы как, хотим ждать чтобы записался Person прежде чем сохранять Order, если заказ для нового клиента делаем?
Или больше хотим не потерять ничего из заказа, и фиг с ним что может быть Person не запишем? (в случае заказа-клиента, конечно, достаточно невероятно, но мало ли).
Так что по требованиям. Надо целостность, делаем FK, надо распараллелить - не делаем FK. Я лично предпочитаю иметь целостные данные. Но иногда надо тупо записать, даже если с ошибками, потом восстановим / спросим пользователя.
Совет: если есть сомнения, не делаем FK. Его можно добавить потом. Пока не поняли что он нам нужен, работаем без него. Иногда неплохо так мешается, а в конце выясняется что целостность нам и не нужна. И вообще, данные о заказчике отдадим в другой сервис.
Надо целостность, делаем FK, надо распараллелить - не делаем FK
Да хороший критерий, хотя второй путь только тогда, когда два агрегата одновременно записываем, похоже.
Но если, я допустим, хочу оценить заказ, то не имея полученного заказа, это сделать еще просто нельзя, тогда значит лучше сделать целостность в этом случае?
какая связь между ДДД и проектированием базы данных?
Если БД не распределенная, какой воспалённый ум может посоветовать таблицу без PK?
Но иногда надо тупо записать, даже если с ошибками
-----
Да почти всегда надо.. не всегда делают - ну так кто им буратно...
По поводу писать без кастомера... нее, пусть будет фейковый кастомер - его проще потом поменять/удалить, чем разбираться с кучей безкастомерных ордеров...
Если БД к распределенная, какой послушный ю воспалённый ум
------
Мелкомягкий.
Один из вопросов на собеседовании - есть куча распределенных серверов на сетях с периодическими пропаданиями соединений. Как на них поместить и как с них получить актуальные данные?
какая связь между ДДД и проектированием базы данных?
Агрегаты маппятся на базу, а не база на агрегаты. Так что по отдельности никак не получится и интересует на ПК, а ФК.
Проблема, в том что во всех примерах, что мне попались никакие ФК не делались и нигде никаких упоминаний не нашел.
Разве что domain mapping.