Вы в статье не упоминаете главного - что проценты, которые вы приводите, нельзя использовать как оценку распределения среди всех ИТ-специалистов. Кто-то может сослаться на вашу статью в стиле "Психолог пишет, что 20% айтишников делают то-то". Фраза "обобщение моего профессионального опыта" является слишком обобщенной. Мне кажется, вам надо добавить явный дисклеймер, что ваши проценты относятся только к тем, кто решил к вам обратиться, и могут быть очень далеки от общей статистики.
Сервисов может быть 100500 и у сервиса по 100500 методов.
Ну значит у бизнеса столько бизнес-сценариев. Значит он имеет свои правила, как они должны работать вместе.
то инварианты придется собирать по всей системе, а также будет тяжело гарантировать их сохранность.
Зачем вам их собирать? Инварианты есть у конкретного бизнес-процесса, у другого процесса свои инварианты. Бизнес сам разберется, чтобы его требования были непротиворечивы. Вам надо только создать их правильную модель в коде.
Некоторые инварианты вообще нельзя гарантировать на уровне одного объекта сущности. Например, нельзя гарантировать правило "Пользователь не должен иметь более 3 статей на модерации", имея доступ только к полям одного объекта Article. Это инвариант процесса "Отправка на модерацию". При этом когда модератор хочет перевести уже опубликованную статью обратно на модерацию, и она становится 4-й для автора статьи, то это должно быть разрешено.
то если существует правило для свойств X и Z, вы рискуете его нарушить.
Если у бизнеса существует такое правило, то оно будет упомянуто в бизнес-требованиях на реализацию бизнес-действий в обоих сервисах. Правила привязаны к процессам, а не к сущностям. Для пользователя некоторое поле обязательно, а когда бизнес через админку редактирует, то нет.
свойства сущности сильно связанные штуки, и потому дистанция до кода, их меняющего, должна быть минимальна.
Ну она и минимальна, связь задается правилами бизнес-процесса, бизнес-процесс описан в методе сервиса, поэтому связь описана максимально близко к бизнес-процессу.
В требованиях нет кейсов на изменение или сброс ссылки.
Ну значит и в вашем коде нет сценариев, которые это делают. Зачем вам делать защиту от ситуации, которая в вашем коде и так невозможна? Если другой программист напишет новый код, который ее меняет, значит у него есть такие требования от бизнеса для его задачи. То есть ваш метод ни от чего не защищает и мешает делать новые задачи. Если у вас возможны какие-то непредусмотренные изменения свойств, значит у вас что-то не так с архитектурой или с процессами разработки.
Я скорее про случаи когда бизнес объект вырождается в DTO с кучей мутабельных свойств типа int или string.
Ну и я про эти случаи.
И совершенно неочевидно, как эти свойства эволюционируют и взаимодействуют меж собой.
Открываете соответствующий метод сервиса, там всё написано. Как свойства эволюционируют и взаимодействуют, задается бизнес-требованиями, вы же их при анализе бизнес-требований и извлекаете.
Но можно чуть иначе LinkOnceToOrder
Вряд ли у вас в бизнес-требованиях описано действие с таким названием, поэтому по DDD такого публичного метода в сущности быть не должно. Разве что приватный, который вызывается из какого-то публичного типа CreateOrder.
Если LinkOnceToOrder вызывается при создании, то и при прямом доступе OrderReference будет устанавливаться один раз, потому что создание заказа вызывается только один раз. Нет необходимости это отдельно проверять.
Линкануть можно единожды
А зачем? Если у вас не было такого требования от бизнеса или хотя бы от разработчиков внешней системы, то и в вашем коде его быть не должно. Вы же говорите про правильную модель. Потом приходят разработчики из внешней системы и говорят "У нас там был сбой, мы вам неправильные номера заказов отправляли, перезапишите новые из вот этого эндпойнта".
Ну я про это и говорю, если бизнес-требования, выраженные в коде, находятся в сущностях, техническая сложность оказывается больше, чем не в сущностях.
Если код не является хорошей моделью релевантных бизнес понятий и процессов
Ну а почему вы считаете, что бизнес-логика в сущностях означает более хорошую модель релевантных бизнес понятий и процессов? С моей точки зрения это менее правильная модель. Заказ не создает сам себя, и бизнес-требованиях не бывает пункта "Заказ должен отправить письмо пользователю о своем создании".
как к методу обменять бизнесовую сложность на техническую
Бизнес-сложность нельзя ни на что обменять, она просто есть, потому что она идет из бизнес-требований. Уменьшить бизнес-сложность можно только изменив бизнес-требования. Техническую сложность к ней можно только добавить. И вот почему-то с логикой в сущностях техническая сложность оказывается значительно больше, чем не в сущностях.
А где тут разница в возможностях на форуме, про которую вы говорили? Ну там юпитер, бык, и всё такое. Возможности, которые предоставляет форум, разные или одинаковые?
оба два этих качества мешают, знаете ли, исподтишка
Оба этих качества мешают и ответные минусы ставить по причине "потому что он мне поставил". Зачем тогда ему неанонимность минусов, о которых шла речь? Если же он хочет поставить минус по другой причине не исподтишка, никто ему не мешает написать в комментариях "Я поставил вам минус".
Неважно, каких привычек у вас нет. Это ответ на ваш вопрос. Ваши комментарии в текущем контексте для меня выглядят как недовольство существованием указанных явлений, с того я и взял. Они так для меня выглядят даже если у вас нет такой привычки.
А можно узнать, чем именно абстрактный «вы» по вашему мнению лучше абстрактного «тролля»?
А где я сказал, что я лучше? Я ставлю минус в карму, если кто-то в комментариях демонстрирует поведение, на мой взгляд неуместное для данного ресурса. У тролля тоже есть такая возможность. Если тролль считает, что мои комментарии неуместны, он тоже может мне поставить минус. Я не знаю, кто поставил мне минус, и не могу поставить троллю минус в ответ если он мне поставил, он не знает и не может поставить. Я зарегистрировался с нулевой кармой, тролль тоже. Где тут разница в возможностях?
С того, что вы на это жалуетесь, указываете, что это не запрещено, и значит другие не должны быть недовольны из-за этого, в обсуждении о том, кому что не нравится в поведении других пользователей.
Минус в карму это выражение не несогласия, а желания "Я хочу, чтобы таких комментариев на ресурсе было меньше". Минус за комментарий такого эффекта не имеет, поэтому и ставить его для этой цели нет смысла.
Ну так если кто-то пишет вам возражение на ваш комментарий, то это и есть его комментарий. Какой еще другой комментарий вам нужен? Я вот написал вам свой комментарий, но вы его не понимаете. Что изменится, если я поставлю вам минус с этим комментарием?
Необоснованные категоричные эмоциональные комментарии вида "Минусование кармы - это способ заткнуть рот" с намеком на низкие моральные качества широкого круга людей вызывают желание, чтобы их было меньше на этом ресурсе.
когда ставя минус в карму, одновременно уменьшаешь и свою
Меня удивляет, что люди в таких советах думают только о себе и не думают, как это будет работать для изначальной цели. Вот есть тролль и есть 10 нормальных пользователей. Пользователи поставили троллю минусы, у них карма уменьшилась на 1. Тролль зарегистрировал новый аккаунт с нулевой кармой, а у нормальных пользователей минусы в карме так и остались. Нафига им это надо?
что равнозначно безнаказанности
Почему тролль, которому поставили минусы, должен иметь возможность кого-то наказывать?
Покажите в правилах пункт, запрещающий ставить минусы в карму за провокационные комментарии. Если такого нет, значит пользователям разрешено это делать. Вы делаете то, что не нравится им, они делают то, что не нравится вам.
Так я же говорю, вам уже написали комменты в упомянутой вами дискуссии, какие еще другие комменты вам нужны? Раз дискуссия, значит есть какие-то возражения, разные взгляды на что-то. Потому что если все со всеми согласны, то и обсуждать нечего.
Автор пытается вести дискуссию, отвечает на комментарии. Чему автор и я можем научиться, что мы должны понять из этих минусов?
Да не из минусов вы должны понять, а из комментариев. Если в комментариях высказывают возражения, то наверно в них и описана причина минусов? Какие еще другие комментарии нужны?
public function query(..., string $query, array $params = []): array { $this->connectionPool->freeConnection($connection); }
У вас на каждый SQL-запрос используется своё подключение, это не будет работать с транзакциями, в реальном приложении это нельзя использовать. В течение всей обработки веб-запроса должно использоваться одно подключение.
Лучше сделать так: для всех изменяющих действий сделать INSERT в таблицу log в той же транзакции, сделать откат транзакции по флагу в GET-параметре с вероятностью 30%, и после завершения бенчмарка проверять, что добавилось то что нужно и ничего не откатилось из-из отката в параллельном запросе. Для UPDATE и DELETE можно добавить предварительный SELECT строки, потому что в приложении обычно надо проверить 404 и 403. Тогда бенчмарки будут иметь практический смысл. Можно проверять 3 сценария отдельно - только запись, только чтение, и поровну. Мне кажется, чем больше операций записи, тем ближе производительность будет к обычному подходу, но наверно все равно немного лучше из-за отсутствия установки подключения к БД. Вопрос в том, насколько. Если разница в пределах 10%, то может и не стоит добавлять из-за этого архитектурную сложность.
Вы в статье не упоминаете главного - что проценты, которые вы приводите, нельзя использовать как оценку распределения среди всех ИТ-специалистов. Кто-то может сослаться на вашу статью в стиле "Психолог пишет, что 20% айтишников делают то-то". Фраза "обобщение моего профессионального опыта" является слишком обобщенной. Мне кажется, вам надо добавить явный дисклеймер, что ваши проценты относятся только к тем, кто решил к вам обратиться, и могут быть очень далеки от общей статистики.
Ну значит у бизнеса столько бизнес-сценариев. Значит он имеет свои правила, как они должны работать вместе.
Зачем вам их собирать? Инварианты есть у конкретного бизнес-процесса, у другого процесса свои инварианты. Бизнес сам разберется, чтобы его требования были непротиворечивы. Вам надо только создать их правильную модель в коде.
Некоторые инварианты вообще нельзя гарантировать на уровне одного объекта сущности. Например, нельзя гарантировать правило "Пользователь не должен иметь более 3 статей на модерации", имея доступ только к полям одного объекта Article. Это инвариант процесса "Отправка на модерацию". При этом когда модератор хочет перевести уже опубликованную статью обратно на модерацию, и она становится 4-й для автора статьи, то это должно быть разрешено.
Если у бизнеса существует такое правило, то оно будет упомянуто в бизнес-требованиях на реализацию бизнес-действий в обоих сервисах.
Правила привязаны к процессам, а не к сущностям. Для пользователя некоторое поле обязательно, а когда бизнес через админку редактирует, то нет.
Ну она и минимальна, связь задается правилами бизнес-процесса, бизнес-процесс описан в методе сервиса, поэтому связь описана максимально близко к бизнес-процессу.
Ну значит и в вашем коде нет сценариев, которые это делают. Зачем вам делать защиту от ситуации, которая в вашем коде и так невозможна? Если другой программист напишет новый код, который ее меняет, значит у него есть такие требования от бизнеса для его задачи. То есть ваш метод ни от чего не защищает и мешает делать новые задачи.
Если у вас возможны какие-то непредусмотренные изменения свойств, значит у вас что-то не так с архитектурой или с процессами разработки.
Ну и я про эти случаи.
Открываете соответствующий метод сервиса, там всё написано.
Как свойства эволюционируют и взаимодействуют, задается бизнес-требованиями, вы же их при анализе бизнес-требований и извлекаете.
Вряд ли у вас в бизнес-требованиях описано действие с таким названием, поэтому по DDD такого публичного метода в сущности быть не должно. Разве что приватный, который вызывается из какого-то публичного типа CreateOrder.
Если LinkOnceToOrder вызывается при создании, то и при прямом доступе OrderReference будет устанавливаться один раз, потому что создание заказа вызывается только один раз. Нет необходимости это отдельно проверять.
А зачем? Если у вас не было такого требования от бизнеса или хотя бы от разработчиков внешней системы, то и в вашем коде его быть не должно. Вы же говорите про правильную модель.
Потом приходят разработчики из внешней системы и говорят "У нас там был сбой, мы вам неправильные номера заказов отправляли, перезапишите новые из вот этого эндпойнта".
Ну я про это и говорю, если бизнес-требования, выраженные в коде, находятся в сущностях, техническая сложность оказывается больше, чем не в сущностях.
Ну а почему вы считаете, что бизнес-логика в сущностях означает более хорошую модель релевантных бизнес понятий и процессов? С моей точки зрения это менее правильная модель. Заказ не создает сам себя, и бизнес-требованиях не бывает пункта "Заказ должен отправить письмо пользователю о своем создании".
Бизнес-сложность нельзя ни на что обменять, она просто есть, потому что она идет из бизнес-требований. Уменьшить бизнес-сложность можно только изменив бизнес-требования. Техническую сложность к ней можно только добавить. И вот почему-то с логикой в сущностях техническая сложность оказывается значительно больше, чем не в сущностях.
Моника Фелула Геллер
У меня есть.
А где тут разница в возможностях на форуме, про которую вы говорили? Ну там юпитер, бык, и всё такое. Возможности, которые предоставляет форум, разные или одинаковые?
Оба этих качества мешают и ответные минусы ставить по причине "потому что он мне поставил". Зачем тогда ему неанонимность минусов, о которых шла речь?
Если же он хочет поставить минус по другой причине не исподтишка, никто ему не мешает написать в комментариях "Я поставил вам минус".
Неважно, каких привычек у вас нет. Это ответ на ваш вопрос. Ваши комментарии в текущем контексте для меня выглядят как недовольство существованием указанных явлений, с того я и взял. Они так для меня выглядят даже если у вас нет такой привычки.
А где я сказал, что я лучше? Я ставлю минус в карму, если кто-то в комментариях демонстрирует поведение, на мой взгляд неуместное для данного ресурса. У тролля тоже есть такая возможность. Если тролль считает, что мои комментарии неуместны, он тоже может мне поставить минус. Я не знаю, кто поставил мне минус, и не могу поставить троллю минус в ответ если он мне поставил, он не знает и не может поставить. Я зарегистрировался с нулевой кармой, тролль тоже. Где тут разница в возможностях?
С того, что вы на это жалуетесь, указываете, что это не запрещено, и значит другие не должны быть недовольны из-за этого, в обсуждении о том, кому что не нравится в поведении других пользователей.
Java и C# на уровне исходного кода практически не отличаются от современного PHP. Классы с методами можно писать в любом из них.
Минус в карму это выражение не несогласия, а желания "Я хочу, чтобы таких комментариев на ресурсе было меньше". Минус за комментарий такого эффекта не имеет, поэтому и ставить его для этой цели нет смысла.
Так, что их ставят разные люди?
Ну так если кто-то пишет вам возражение на ваш комментарий, то это и есть его комментарий. Какой еще другой комментарий вам нужен? Я вот написал вам свой комментарий, но вы его не понимаете. Что изменится, если я поставлю вам минус с этим комментарием?
Необоснованные категоричные эмоциональные комментарии вида "Минусование кармы - это способ заткнуть рот" с намеком на низкие моральные качества широкого круга людей вызывают желание, чтобы их было меньше на этом ресурсе.
Меня удивляет, что люди в таких советах думают только о себе и не думают, как это будет работать для изначальной цели. Вот есть тролль и есть 10 нормальных пользователей. Пользователи поставили троллю минусы, у них карма уменьшилась на 1. Тролль зарегистрировал новый аккаунт с нулевой кармой, а у нормальных пользователей минусы в карме так и остались. Нафига им это надо?
Почему тролль, которому поставили минусы, должен иметь возможность кого-то наказывать?
Покажите в правилах пункт, запрещающий ставить минусы в карму за провокационные комментарии. Если такого нет, значит пользователям разрешено это делать. Вы делаете то, что не нравится им, они делают то, что не нравится вам.
Минусование кармы - это не способ заткнуть рот, и в основном с аргументацией.
Так я же говорю, вам уже написали комменты в упомянутой вами дискуссии, какие еще другие комменты вам нужны? Раз дискуссия, значит есть какие-то возражения, разные взгляды на что-то. Потому что если все со всеми согласны, то и обсуждать нечего.
Да не из минусов вы должны понять, а из комментариев. Если в комментариях высказывают возражения, то наверно в них и описана причина минусов? Какие еще другие комментарии нужны?
У вас на каждый SQL-запрос используется своё подключение, это не будет работать с транзакциями, в реальном приложении это нельзя использовать. В течение всей обработки веб-запроса должно использоваться одно подключение.
Лучше сделать так: для всех изменяющих действий сделать INSERT в таблицу log в той же транзакции, сделать откат транзакции по флагу в GET-параметре с вероятностью 30%, и после завершения бенчмарка проверять, что добавилось то что нужно и ничего не откатилось из-из отката в параллельном запросе. Для UPDATE и DELETE можно добавить предварительный SELECT строки, потому что в приложении обычно надо проверить 404 и 403. Тогда бенчмарки будут иметь практический смысл. Можно проверять 3 сценария отдельно - только запись, только чтение, и поровну. Мне кажется, чем больше операций записи, тем ближе производительность будет к обычному подходу, но наверно все равно немного лучше из-за отсутствия установки подключения к БД. Вопрос в том, насколько. Если разница в пределах 10%, то может и не стоит добавлять из-за этого архитектурную сложность.