Добрый вечер. Недавно прочитал синюю книжку Эванса, осталось пару вопросов.

Question

Добрый вечер. Недавно прочитал синюю книжку Эванса, осталось пару вопросов.

Если кто-то сможет ответить - буду благодарен.
1) В книге упоминается shared kernel. Есть ли кейсы, когда туда помещается что-то помимо инфраструктурных реализаций, либо VO? И собственно вопрос в ту же сторону. В 2 контекстах допустим VO "сумма", которая не может быть мешьше 100. Все ок, пока не приходит еще один контекст, где инвариант "Суммы" становится < 200. Правильно ли, что тогда этот VO убирается из shared kernel'а и помещается в каждый контекст отдельно? Тут скорее переформулирую: если что-то упоминается в shared kernel, то оно во всех контекстах должно однозначно определяться, а не в нескольких только?
2) Про общения между контекстами немного остались непонятны различия между трансляцией и антикоррапшном. Правильно ли утверждение, что антикоррапшн - это когда чужой контекст не знает о тебе ничего, однако ты делаешь "обработку" в свой "нужный домену" формат. А собственно трансляция - это когда 2 контекста знают друг о друге и вместе собственно строят эту самую связь. По сути с точки реализации "транслятор" - это acl'ы с двух сторон, грубо говоря?

#oop #programming #russian #software #web-design

0

07.09.2021

1 ответов

22 просмотра

Sergey P · Accepted Answer

shared kernel - как и все "общие" вещи должен быть максимально тонким. Что именно - решать командам которые работыют над разными контекстами. Как правило это какие-то общие понятия которые позволяют вам "линковать" контексты между собой. Типичный пример - какие-нибудь VO для идентификаторов. Скажем UserId или ProductId какой. То что обозначает идентификатор "большой" бизнес-сущности на который будут ссылаться ее части из разных контекстов. На тему DTO в shared kernel - опять же часто бывают какие-то типичные штуки типа дэйт рэйджин и т.д. которые "почему бы не сложить вместе", но лучше выбирать стратегию "выносить в общий кернел только то что встречается в разных контекста больше чем 2 раза, и только если вы уверены что концепт достаточно простой и не будет меняться по своим причинам". То есть вот "сумма" про которую ты говоришь - я бы по умолчанию воспринимал такие вещи как что-то что должно быть строго в своих контекстах и т.д. Еще хороший кейс для shared kernel - это скажем доменные ивенты которые используются для интеграции (то что у Фаулера в классификации event driven как event notification). причем шаред кернел не обязательно обязан быть прям кодом и модулем приложения, это может быть просто набор контрактов для grpc например или там еще какая asyncapi спека. Например если ты упарываешься по микросервисам. Важно - это маленький сабсэт всех доменных ивентов в системе. Цель shared kernel - больше не "реюз кода" а скорее общие элементы контракта которые вы хотите иметь между контекстами. На тему транслейшенов и anti corruption layer. Для начала анти коррапшен лэйер это та штука которая занимается трансляцией, то есть такой слой адаптеров который позволяет линковать "внешние" контексты и твои контексты. Хорошо сочитается с интеграцией с внешними системами или когда есть легаси части которые еще не распилили. Тут ключевой момент - контроль за изменениями. Если контроль не с твоей стороны то ACL тебе нужен просто что бы защитить модель от возможных изменений чужой модели. То есть это не про "две команды которые работают над своими контекстами" а прям "две организации или две принципиально разные модели которые могут меняться независимо".

212 похожих чатов

Добрый вечер. Недавно прочитал синюю книжку Эванса, осталось пару вопросов.

1 ответов

Похожие вопросы