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