Типа если что-то очень очень generic (как Date или BigDecimal),

то рассматривать его в рамках контекстов из DDD нет смысла?

Нет

А если я всё таки выделю этот супер-пупер generic domain в context map, то какие минусы?

А можно узнать что меняется для вас в зависимости от того что оно выделено и как обозвано ? Просто в моем мире это меняет ровным самом ничего.

Тоже ничего не меняет. Просто разбираюсь в философии DDD

Могу порекомендовать тогда ADSD от Udi посмотреть. Мне больше помогло в ддд разобраться чем сам ддд

Философия DDD заключается в том что бы разбираться и изучать предметную область, "переработка знаний", как Эванс пишет. О том кто зачем и как системой пользуется и как система влияет на бизнес. Стратегическое DDD - как понять из каких кусков состоит система, как разбить ее таким образом что бы там где важно инвестировать а где не важно взять готовое (generic контексты). Как обеспечить автономность принятия большинства решений. Тактическое DDD - как защитить процессы от влияния инфраструктуры и внешнего мира. Влияния именно на то какие ограничения "внешний мир" накладывает. Как их вписать в то что надо бизнесу. Это вообще мало про код. Это про снижение стоимости перевода требований с языка пользователей/стэйкхолдеров в реализацию. Как мол из problem space к solution space придти и как они друг с другом соотносятся. It's about journey, not the destination

Dmitry Croft
Ну да, но зачем-то generic domain у эванса описан

Дженерик домен это всякие логины, аудиты, прочий commodity булшит который нужен для функционирования системы но его можно либо на аутсорс отдать либо взять from the shelf решения. Это "решённые проблемы"

Он там пишет, что есть very generic домен по работе с деньгами. Это разве не может быть BigDecimal? Его тоже можно взять rom the shelf

Да, можно

> Стратегическое DDD - как понять из каких кусков состоит система, как разбить ее таким образом что бы там где важно инвестировать а где не важно взять готовое (generic контексты). Как обеспечить автономность принятия большинства решений. ну так проблема, которую я выше описывал с датами, тоже под это подходит. Да, есть вопросы к тому стоит ли рисовать на context map, но всё же

и это тот же самое решение rom the shelf

Другая аналогия - тебе надо логин профиль пользователя и т.д. можно пилить свой "контекст" а можно взять keycloak/okta/auth0/authn и т.д.

Да, я это понимаю

Ну, по работе с деньгами у меня был только один вопрос - отдавать ли расчет на клиента или внутри расчитывать. В какое-то время думал внедрить функцию расчёта - но потом реально решил - пусть клиент либы вычисляет, а либа лишь предоставляет модель расчёчтов

с деньгами через floating point работает?

работает, как ни странно))

А как проблема с неточностью решена?

А никак - модель не нуждается в "точности"

Первый же тест: 0.1 + 0.2 === 0.3

Получается, ты решил проблему, которую никто не мог решить

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

Ну вот с виду вроде должно работать, просто интересно узнать можно ли однозначно доказать, что это работает

Думаю, да. Достаточно показать, что погрешность не достигает 0.005

Это да, я говорил про случай с округлением 64 битный флоатов после каждой операции до N после запятой. Интересно как можно доказать, что проблем не будет

Я слышал, что требования к округлению оговариваются с бизнесом, чтобы не было проблем

Это да, но мы обсуждали чисто технический кейс с флоатами

Но зачем их вообще использовать при подсчёте денег? В чем преимущество перед условным BigDecimal?

Мы обсуждали хак с округлением после каждой операции до N цифр после запятой. Про преимущества не говорили