Телеграмм чат группы oop

devsecgitnettechops - вот такой бутерброд можно сложить

19:53пожаловаться #1

А еще пару вопросов.

Хориков приводит пример Date/DateTime как пример волатильной зависимости на которую предметная область не должна завязываться.

Объекты Date/DateTime это еще и внепроцессная зависимость или только волатильная зависимоcть?
Какой практический смысл изолировать предметную область от Date/DateTime?

19:54пожаловаться #2

хотя идея примитивна - "давайте мы будем думать об operations во время dev"

19:54пожаловаться #3

так мы можем пойти дальше - давайте не будем завязываться от языка программирования, он же тоже волатильная зависимость. Давайте будем для каждого продукта делать свой DSL

19:55пожаловаться #4

ты хочешь обезопасить себя от:

- влияния инфраструктуры и ограничений инфраструктуры на возможности бизнес логики
- уменьшить вероятность каскада изменений за счет изоляции зависимостей которые меняются слишком часто. объекты стандартной библиотеки крайне стабильны.

19:56пожаловаться #5

Понял. Это все по ситуации, значит

19:57пожаловаться #6

проблема в том что не надо "предметную область" воспринимать как что-то одно. аутентификация - у нее свой под домен и там хэширование пароля может быть частью бизнес логики. Почему бы нет. Но не надо это на один уровень смещать с логикой вычисления скидов например. Или еще чем-нибудь.

20:03пожаловаться #7

Ну вот я тоже так считаю. Но когда гуглил вопрос, натыкался на та утвеждения что это все только инфраструктура

20:04пожаловаться #8

а быть может все DDD для такого дженерик контекста будет заканчиваться границами контекста и точками интеграции с ним - пример - твоей системе нужна система тикетов для суппорта. Ты можешь ее дизайнить по DDD там и обмазываться своими слоями. А можешь купить helpdesk какой клаудовый и интегрировать.

20:04пожаловаться #9

Я понимаю, что разные контексты могут быть реализованы по своим правилам. Меня просто сбивали утверждения, что хеширование это только инфраструктура

20:05пожаловаться #10

по-моему практический смысл в том, что ты например можешь сделать тесты на нужный тебе момент времени. А если new DateTime будет внутри, то придётся упражняться во всяких там таймстопах и прочих стабах.
Ну и в целом могут быть кейсы когда надо "задним числом" что-то делать

20:18пожаловаться #11

Ну вот, наверное, только в случаях где есть логика связанная со временм. А если это обычные createdAt/updateAt, наверное, смысла нет

20:20пожаловаться #12

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

20:23пожаловаться #13

реализация - да. контакт может быть в домене

20:23пожаловаться #14

по сути можно на это с другой стороны смотреть - пытаемся изолировать домен от сайд эффектов. та же генерация соли это сайд эффект.

20:24пожаловаться #15

скорее всего ты можешь даже код не писать для таких createdAt, а просто default колонки в бд сделать, но это уже детали реализации

20:26пожаловаться #16

ну если у тебя default колонки значит у тебя невалидные сущности что тоже расходится с идеей, think about it

20:28пожаловаться #17

если у тебя эти колонки нужны только для того, чтобы в UI показать даты, то не расходится.
Тут случай с круд-ом имхо

20:29пожаловаться #18

Мне кажется если для ui, то как раз расходится. Типа как может в ui попасть то, что не было создано в ходе бизнес транзакции. А если чисто для аудита, то нет. Ну наверное

20:41пожаловаться #19

Вот даже пои смене бд это все пропасть может. Юнит тесты не зафейлят. А интеграционные все переписывать и так