согласен и даже добавлю - юс кейс не обязан включать в себя функционал по изменению состояния системы.
Вроде в книжке Роберта Мартина он их не разделяет, да, тут ошибка вышла.
И так, принцип Open–closed principle связан с примером, где поястоянно вносятся изменения в один класс (для атрибутов задается значение по умолчанию, равное Null/None/...), из-за того что появляются новые юс-кейсы со своими потребностями.
У тебя неправильное понимает этого принципа. Open-Closed principle - не про "нельзя менять старый код, можно добавлять только новый", он про изменение работы метода, не меняя сам метод. Например, наследование от класса и переопределение метода, или разбить метод на функции, занижектить их в наш объект и вызывать внутри метода, и, в случае, если что-нибудь нужно будет изменить, мы будем менять функции, которые мы заинжектили, а не наш метод, и т.д.
Там (как и большинстве технической литературы) явного ответа как поступать в таких кейсах - нет
Ну как нет то? В DDD принято грузить полностью агрегат для выполнения какой то операции, которая может не потребовать и половины данных, которые ты загрузил. Ну, или вспомнить даже знаменитую триллему, где иногда прибегают к потери производительности, чтобы не потерять 2 других свойства домена.
Тоже об этом думал, но если в доменная сущность претерпит какие-то сильные/глобальные измения - эти измения небохдоимо применить во всех местах, где это потребуется.
Если ты порежешь приложение по юзкейсам, то будет разумно, в каждом юзкейсе создавать свою сущность, которая может быть похожа на сущность из другого юзкейса, но тем не менее, будет иметь другой смысл. Но если у тебя появляется такая необходимость - значит домен сложный и тут лучше делать на агрегаты, а не на анемичные модели.
Просто дели на модели для представления и на модели для бизнес логики, а все остальное это мелочи, и не надо забивать этим голову.
У пользователя есть права доступа, к каждому контекту свои
У пользователя не может быть прав к "контексту", у пользователя могут быть права к каталогу или блогу в контексте личного кабинета, это не тоже самое, что личный кабинет знает о контексте блога или каталога, это именно блог или каталог в контексте личного кабинета
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Вроде в книжке Роберта Мартина он их не разделяет, да, тут ошибка вышла.
У тебя неправильное понимает этого принципа. Open-Closed principle - не про "нельзя менять старый код, можно добавлять только новый", он про изменение работы метода, не меняя сам метод. Например, наследование от класса и переопределение метода, или разбить метод на функции, занижектить их в наш объект и вызывать внутри метода, и, в случае, если что-нибудь нужно будет изменить, мы будем менять функции, которые мы заинжектили, а не наш метод, и т.д.
Ну как нет то? В DDD принято грузить полностью агрегат для выполнения какой то операции, которая может не потребовать и половины данных, которые ты загрузил. Ну, или вспомнить даже знаменитую триллему, где иногда прибегают к потери производительности, чтобы не потерять 2 других свойства домена.
Если ты порежешь приложение по юзкейсам, то будет разумно, в каждом юзкейсе создавать свою сущность, которая может быть похожа на сущность из другого юзкейса, но тем не менее, будет иметь другой смысл. Но если у тебя появляется такая необходимость - значит домен сложный и тут лучше делать на агрегаты, а не на анемичные модели.
Просто дели на модели для представления и на модели для бизнес логики, а все остальное это мелочи, и не надо забивать этим голову.