Операция – это всего лишь то, что находится во временном интервале: «с» и «по». Если точность наших измерений не позволяет различить «с» и «по», и они сливаются, то мы получаем событие с датой «когда».
Почему операция вдруг превращается в событие? Откуда вообще здесь взялись события если это "продолжительная операция" (с/по) и "одномоментная операция" (когда)?
Трансформатор для эксплуатации и трансформатор для учета материального учета – разные объекты. [...] То есть, один и тот же 4-Д объем может трактоваться как физический трансформатор или как функциональный трансформатор.
Таки разные или одинаковые?
Я бы сказал, что это разные объекты в разных Bounded Context и соответственно с разными 4-Д объемами.
Изменение – это сценарий, а не операция и не событие.
Разве? Мне всегда казалось, что — сценарий выполняет операциюизменения которая триггерит событие.
Но, уточняя модель, мы все равно наткнемся на событие, в котором свет и темнота существуют вместе.
Поясните пожалуйста, что вы имеете в виду под событием в данном случае?
Если это событие которое триггерится на изменение состояния, то я не вижу проблем в сосуществовании света и тени (красный и белый) в одном событии. Хотя в случае если состояний ограниченное количество, как в случае со светом, лучше подойдут типизированные события в духе: в помещении А включили свет.
Так я и не говорю "как взломать соседа". Я говорю, что последствия взлома сосед не проблема архитектуры SSL, а проблема самого взлома соседа.
Уже много раз встречал подобные заявления и каждый раз умиляюсь.
Почему-то все забывают, что если Почтальон взломает Бориса, то Почтальон станет Борисом со всеми вытекающими последствиями. И SSL здесь вообще не при делах.
каким-то образом (социальная инженерия, взлом с проникновением) прописать свой фейковый корневой центр сертификации в реестр Бориса.
В случае взлома, Почтальон уже имеет полный контроль над устройством и ему проще просто установить следящее ПО, майнинг Биткоино и тд, чем развлекаться с сертификатами. Он уже может больше чем просто слушать и изменять трафик.
Та же ситуация с социальной инженерией. Гараздо проще уговорить пользователя два раза кликнуть на exe, чем лезть в сертификационный центр. С этой задачей не каждый продвинутый пользователь справится, что уж говорить о бугалтерушечках.
Я говорю как раз о фактической безопасности сайта. Для пользователей будет все очевидно:
Красный — не безопасно. Не безопасно соединение и как следствие сам сайт.
Нет цвета — возможно безопасно, а может и нет. Соединение безопасно, а вот что с сайтом не известно.
Зелёный — безопасно. Зелёное только для EV сертификатов которые выдаются только юрлиццам и с кучей бумажной волокиты. Сайты под EV достаточно серьезно заботятся о своей безопасности и безопасности своих пользователей. Взломать конечно могут и сайт под EV сертификатом, но вероятность этого ниже. И если не доверять сайтам под EV, то вообще никому доверять нельзя.
Вот мы и получаем, что обозначение будет значительно лучше соответствовать фактической безопасности сайта. И для юзеров это будет нагляднее.
Хотя, пожалуй сайты под EV лучше все же сделать желтыми ибо безопасность не 100%
Я с вами полностью согласен, что "безопасный сайт" и "безопасное соединение с сайтом" это разные понятия. Я вам о другом говорю.
Посмотрите скрин в начале статьи с пометкой "В будущем". Скоро не будут писать ни каких "Защищено". Будут писать только "Не безопасно", что уже намного ближе к правде.
Если соединение с сайтом не защищено, то и сайт не защищен и пользователь не защищен. А если соединение с сайтом защищено, то нет гарантий, что сайт и пользователь защищены и значков говорящих об этом или обратном больше не будет.
Акцент меняется. Раньше было HTTPS это хорошо, а HTTP ну такое, а теперь будет HTTPS ну такое, а HTTP вообще ад. Если раньше Chrome говорил, что сайту с HTTPS можно доверять, то скоро этого не будет. И только избранные, с сертификатом EV, смогут говорить, что им можно доверять.
То есть, по факту, скоро обозначение безопасности сайта в Chrome будет на много ближе фактической безопасности сайта.
Получается как раз наоборот. Если на сайте есть HTTPS, то просто не выводится значек Not secure.
Если раньше Chrome говорил, что сайт с HTTPS безопасный и ему можно полностью доверять, то теперь этого не будет.
Как взаимодействуют друг с другом родительский и дочерние контексты, а так же дочерние друг с другом?
Моя практика показывает, что иерархическая структура контекстов хорошо работает когда есть множество небольших контекстов ни как не связанных между собой и другими контекстами, но имеющие общий контекст. Общий контекст, в этом случае, может быть пустым. Своего рода группа контекстов.
Порой, общий/родительский контекст имеет свою логику и дочерние контексты в этом случае имеют к нему доступ (дерево. Все связи направлены в низ, к основанию). Это может делаться для вынесения одинаковой бизнес логики, чтоб не дублировать её в каждом контексте. Не смотря на наличие схожих бизнес процессов, это все ещё разные контексты, которые ни как нельзя объединять в один большой контекст.
Моя практика показывает, что дублирование бизнес процессов в разных контекстах не самое лучшее решение, даже если это дублирование только формальное, на бумаге.
А вот выделение субконтекстов из основного контекста для их изоляции, как в примере с страницами и комментариями, дело довольно спорное, как вы уже подметили.
Если говорим о чём-то типа Хабра, то интеграция нужна.
И опять вы выносить домен в уровень представления. Сначало говорили, что аннотация в домене это протечка инфраструктуры, а теперь сами же вытаскиваете домен в представление.
А если серьезно, то посмотрите хотя бы на эту страницу. Только ли статья на ней и только ли комментарии? На странице есть как минимум сущности из контекста аунтификации, что значит, что сосуществование разных контекстов в одном запросе на уровне представления это норма. И к API это тоже относится.
Как минимум это заставит создавать отдельный модуль интгерации контекстов и страниц, не позволит выбирать комментарии со страницами одним SQL-запросом или хранить их в рамках одного документа в базах типа MongoDB.
Зачем модули интеграции если их не нужно интегрировать?
Один SQL запрос так и так нельзя использовать для извлечения одной страницы и всех её комментариев.
Документ в монге это конечно аргумент, но если использовать монгу как read хранилище, то можно. Структуру read хранилища определяет уровень представления, а не домен.
Я просто пытаюсь понять, какие плюсы в разделении контекстов страниц и комментариев.
Кажется я об этом уже говорил. Критерием для разделения контекстов их размер.
Учитывая сколько мы всего описали только для учёта просмотра страниц, не сложно прикинуть, что контекст получается ой как не маленький. Отсюда и вывод, что нужно делить контекст на контексты поменьше.
Надеюсь не нужно объяснять чем плохи больше контексты?
Я вам говорю о базовых принципах не однократно описанные множеством известных специалистов. Вы можете пренебрегать этими принципами. Это ваше право.
А как на фронте понять что нужно обновлять счётчик?..
Я разве говорил, что нужно понимать это на фронте? Нет. Я говорил, что вы можете отправлять на сервер сообщения о просмотре, по аналогии с GA и YM, а на сервере уже применять просмотры в соответствии с вашей бизнес логикой.
У Вас уже логика прямо на фронте получилась.
Нет. Хотя она там может быть. Вспоминаем SPA.
А на беке получается паутина из обработчиков событий. При этом это один use case.
Паутины нет. События только так где они действительно нужны.
Вы говорити, что Use case один, а так ли это?
Получить пост из хранилища;
Пометить пост как просмотренный;
Поставить бейдж популярному посту;
Обновить блок популярных постов;
Обновить топ на главной;
Обновить статистику просмотров поста у автора в профиле;
Обновить статистику просмотров в админке;
...
Вы собираетесь запихивать все это в один Use case, в один метод, в один GET запрос и пусть весь мир подождёт)))
Совершенно верно. Большие контексты плохо и совсем маленькие контексты тоже плохо. Нужно искать золотую середину. Моя золотая середина это два отдельных контекста комментарии и страницы. Ваша золотая середина это комментарии и страницы в одном контексте. Я уже устал это повторять. Давайте завязывать.
но всё равно нужно записать это в базу в пределах одной транзакции с получением результата запроса.
Ещё раз. Почему в пределах именно одной транзакции? Почему нельзя обработать запрос в фоне?
Даже если вы не используете Commad и Query, а используете методы, то почему метод в духе getPage() должен ещё и писать что-то? Кидать событие, да возможно, но не писать.
Я с самого начала говорил о комментаторе, но называл его автором комментариев. Я уже давно поправился.
Пока это выглядит так, что вы просто любую мало-мальски значимую сущность вытаскиваете в отдельный контекст по умолчанию.
Ну во первых, сущность комментариев не такая уж и "мало-мальски значащая". Мы сейчас общаемся на Хабре в комментариях и я, обсуждая комментарии, ассоциирую их с комментариями Хабра, а комментарии на Хабре не такие уж и мало значащие.
Во вторых, да. Контексты должны быть маленькими. Чем меньше контексты, тем они оптимальней. Большие контексты сродни отсутствию контекстов вообще. Если мне память не изменяет, то именно Вернон говорил об этом в своей книге. Рекомендую почитать если вы ещё не читали.
Разве? Вроде и по Ubiquitous Language прошлись. Напоминаю:
User — в контексте страниц пользователь является автором страниц;
User — в контексте комментариев к страницам пользователь является комментатором.
Можем ещё модераторов добавить.
User — модератор страниц;
User — модератор комментариев;
Модератор страниц может подтвердить или отклонить публикацию страницы;
Модератор комментариев может удалить или заблокировать комментарий.
Можем ещё пробежаться по Use cases страниц и комментариев.
Я повторюсь. Я предлагаю разделить комментарии и страницы на отдельные контексты. Вы можете со мной не согласится и сделать по своему. Я не царь и бог чтоб неповиновение мне каралось смертной казнью)))
Так и думал, что у вас проблемы с архитектурой.
Начнем с простого. Вы в read потоке выполняете запись. Это уже не правильно.
Далее, с чего вы решили, что вам обязательно дожидаться обновления хранилища прежде чем отдавать контент пользователю?
Обновлять щетчики просмотров можно 2 способами. Можно на fronend через js или картинки по аналогии с другими метриками. Можно на backend кидать event "страница просмотрена".
Первый вариант предпочтительней так как в этом случае вы можете полностью или частично закешировать страницу и не дергать бекенд лишний раз. А щетчики на странице в этом случае обновлять через API.
Но даже в случае второго способа с event, вы просто его бросаете и read поток на этом заканчивается. Событие подхватывает слушатель который ставит в очередь команду на обновление щетчика и в обработчике команды, который будет вызван в фоне, вы уже поднимаете домен, применяете свою бизнес логику и обновлять хранилища.
Для оптимизации можно в слушателе события обновлять щетчик в Redis, значение которого сразу пойдет во view, а в процессе обработки просмотра в фоне откатывать щетчики для неугодных просмотров.
Подведя итог, для работы щетчиков поднимать домен не нужно.
Страница вывода поста — обращение как минимум к «посты», «комментарии» и «пользователи», блок «Самые комментируемые посты» — обращение как минимум к контекстам «посты» и «комментарии».
Повторюсь. Это Read поток. Для оптимизации нагрузки рекомендуется не использовать домен на этом уровне (см. CQRS). Для оптимизации нагрузки все эти данные, как правило, кладутся в NoSQL хранилища или вытягиваются простыми запросами к БД и не строят многоуровневые агрегаты, а используются DTO или вообще массивы.
Домен нужен для того, чтоб сформировать бизнес логику обработки Write потока, а доменные события тригерят обновление кеша и снепшотов для Read потока.
Это мнение Эванса и Вернона и я с ними солидарен. Я не хочу сказать, что все должны делать так, но там где есть выделенный домен, как правило задумываются о разделении read и write потоков.
Вот вопрос скорей стоял где та гран
Грань каждый определяет сам. Есть некоторые рекомендации описанные в книгах по DDD, но четких правил нет.
Почему операция вдруг превращается в событие? Откуда вообще здесь взялись события если это "продолжительная операция" (с/по) и "одномоментная операция" (когда)?
Таки разные или одинаковые?
Я бы сказал, что это разные объекты в разных Bounded Context и соответственно с разными 4-Д объемами.
Разве? Мне всегда казалось, что — сценарий выполняет операцию изменения которая триггерит событие.
Поясните пожалуйста, что вы имеете в виду под событием в данном случае?
Если это событие которое триггерится на изменение состояния, то я не вижу проблем в сосуществовании света и тени (красный и белый) в одном событии. Хотя в случае если состояний ограниченное количество, как в случае со светом, лучше подойдут типизированные события в духе: в помещении А включили свет.
Так я и не говорю "как взломать соседа". Я говорю, что последствия взлома сосед не проблема архитектуры SSL, а проблема самого взлома соседа.
Уже много раз встречал подобные заявления и каждый раз умиляюсь.
Почему-то все забывают, что если Почтальон взломает Бориса, то Почтальон станет Борисом со всеми вытекающими последствиями. И SSL здесь вообще не при делах.
Как я люблю такие заявления:
В случае взлома, Почтальон уже имеет полный контроль над устройством и ему проще просто установить следящее ПО, майнинг Биткоино и тд, чем развлекаться с сертификатами. Он уже может больше чем просто слушать и изменять трафик.
Та же ситуация с социальной инженерией. Гараздо проще уговорить пользователя два раза кликнуть на exe, чем лезть в сертификационный центр. С этой задачей не каждый продвинутый пользователь справится, что уж говорить о бугалтерушечках.
Я говорю как раз о фактической безопасности сайта. Для пользователей будет все очевидно:
Вот мы и получаем, что обозначение будет значительно лучше соответствовать фактической безопасности сайта. И для юзеров это будет нагляднее.
Хотя, пожалуй сайты под EV лучше все же сделать желтыми ибо безопасность не 100%
Я с вами полностью согласен, что "безопасный сайт" и "безопасное соединение с сайтом" это разные понятия. Я вам о другом говорю.
Посмотрите скрин в начале статьи с пометкой "В будущем". Скоро не будут писать ни каких "Защищено". Будут писать только "Не безопасно", что уже намного ближе к правде.
Если соединение с сайтом не защищено, то и сайт не защищен и пользователь не защищен. А если соединение с сайтом защищено, то нет гарантий, что сайт и пользователь защищены и значков говорящих об этом или обратном больше не будет.
Акцент меняется. Раньше было HTTPS это хорошо, а HTTP ну такое, а теперь будет HTTPS ну такое, а HTTP вообще ад. Если раньше Chrome говорил, что сайту с HTTPS можно доверять, то скоро этого не будет. И только избранные, с сертификатом EV, смогут говорить, что им можно доверять.
То есть, по факту, скоро обозначение безопасности сайта в Chrome будет на много ближе фактической безопасности сайта.
Получается как раз наоборот. Если на сайте есть HTTPS, то просто не выводится значек Not secure.
Если раньше Chrome говорил, что сайт с HTTPS безопасный и ему можно полностью доверять, то теперь этого не будет.
Моя практика показывает, что иерархическая структура контекстов хорошо работает когда есть множество небольших контекстов ни как не связанных между собой и другими контекстами, но имеющие общий контекст. Общий контекст, в этом случае, может быть пустым. Своего рода группа контекстов.
Порой, общий/родительский контекст имеет свою логику и дочерние контексты в этом случае имеют к нему доступ (дерево. Все связи направлены в низ, к основанию). Это может делаться для вынесения одинаковой бизнес логики, чтоб не дублировать её в каждом контексте. Не смотря на наличие схожих бизнес процессов, это все ещё разные контексты, которые ни как нельзя объединять в один большой контекст.
Моя практика показывает, что дублирование бизнес процессов в разных контекстах не самое лучшее решение, даже если это дублирование только формальное, на бумаге.
А вот выделение субконтекстов из основного контекста для их изоляции, как в примере с страницами и комментариями, дело довольно спорное, как вы уже подметили.
Это как посмотреть на вопрос.
Если контекст единый, то при комментарии, в самом комментарии, мы должны убедиться, что статья опубликована и в противном случае выбросить исключение.
Если же контексты раздельные, то не опубликованных статей в контексте комментариев просто не будет существовать.
Вот вам и преимущество разделения.
И опять вы выносить домен в уровень представления. Сначало говорили, что аннотация в домене это протечка инфраструктуры, а теперь сами же вытаскиваете домен в представление.
А если серьезно, то посмотрите хотя бы на эту страницу. Только ли статья на ней и только ли комментарии? На странице есть как минимум сущности из контекста аунтификации, что значит, что сосуществование разных контекстов в одном запросе на уровне представления это норма. И к API это тоже относится.
Об том и спич
Кажется я об этом уже говорил. Критерием для разделения контекстов их размер.
Учитывая сколько мы всего описали только для учёта просмотра страниц, не сложно прикинуть, что контекст получается ой как не маленький. Отсюда и вывод, что нужно делить контекст на контексты поменьше.
Надеюсь не нужно объяснять чем плохи больше контексты?
Я вам говорю о базовых принципах не однократно описанные множеством известных специалистов. Вы можете пренебрегать этими принципами. Это ваше право.
Я разве говорил, что нужно понимать это на фронте? Нет. Я говорил, что вы можете отправлять на сервер сообщения о просмотре, по аналогии с GA и YM, а на сервере уже применять просмотры в соответствии с вашей бизнес логикой.
Нет. Хотя она там может быть. Вспоминаем SPA.
Паутины нет. События только так где они действительно нужны.
Вы говорити, что Use case один, а так ли это?
Вы собираетесь запихивать все это в один Use case, в один метод, в один GET запрос и пусть весь мир подождёт)))
Нет. Событие это сообщение возникающие в процессе выполнения программы. Само по себе событие ничего не меняет.
Совершенно верно. Большие контексты плохо и совсем маленькие контексты тоже плохо. Нужно искать золотую середину. Моя золотая середина это два отдельных контекста комментарии и страницы. Ваша золотая середина это комментарии и страницы в одном контексте. Я уже устал это повторять. Давайте завязывать.
Ещё раз. Почему в пределах именно одной транзакции? Почему нельзя обработать запрос в фоне?
Даже если вы не используете Commad и Query, а используете методы, то почему метод в духе
getPage()должен ещё и писать что-то? Кидать событие, да возможно, но не писать.Я с самого начала говорил о комментаторе, но называл его автором комментариев. Я уже давно поправился.
Ну во первых, сущность комментариев не такая уж и "мало-мальски значащая". Мы сейчас общаемся на Хабре в комментариях и я, обсуждая комментарии, ассоциирую их с комментариями Хабра, а комментарии на Хабре не такие уж и мало значащие.
Во вторых, да. Контексты должны быть маленькими. Чем меньше контексты, тем они оптимальней. Большие контексты сродни отсутствию контекстов вообще. Если мне память не изменяет, то именно Вернон говорил об этом в своей книге. Рекомендую почитать если вы ещё не читали.
Разве? Вроде и по Ubiquitous Language прошлись. Напоминаю:
Можем ещё модераторов добавить.
Можем ещё пробежаться по Use cases страниц и комментариев.
Я повторюсь. Я предлагаю разделить комментарии и страницы на отдельные контексты. Вы можете со мной не согласится и сделать по своему. Я не царь и бог чтоб неповиновение мне каралось смертной казнью)))
Так и думал, что у вас проблемы с архитектурой.
Начнем с простого. Вы в read потоке выполняете запись. Это уже не правильно.
Далее, с чего вы решили, что вам обязательно дожидаться обновления хранилища прежде чем отдавать контент пользователю?
Обновлять щетчики просмотров можно 2 способами. Можно на fronend через js или картинки по аналогии с другими метриками. Можно на backend кидать event "страница просмотрена".
Первый вариант предпочтительней так как в этом случае вы можете полностью или частично закешировать страницу и не дергать бекенд лишний раз. А щетчики на странице в этом случае обновлять через API.
Но даже в случае второго способа с event, вы просто его бросаете и read поток на этом заканчивается. Событие подхватывает слушатель который ставит в очередь команду на обновление щетчика и в обработчике команды, который будет вызван в фоне, вы уже поднимаете домен, применяете свою бизнес логику и обновлять хранилища.
Для оптимизации можно в слушателе события обновлять щетчик в Redis, значение которого сразу пойдет во view, а в процессе обработки просмотра в фоне откатывать щетчики для неугодных просмотров.
Подведя итог, для работы щетчиков поднимать домен не нужно.
Так в этом и смысл. Незачем городить DDD в CRUD приложениях.
Под "Не менее важная логика" вы подразумеваете бизнес ограничения?
Вы можете привести какой нибудь пример, чтоб мы говорили более предметно?
Повторюсь. Это Read поток. Для оптимизации нагрузки рекомендуется не использовать домен на этом уровне (см. CQRS). Для оптимизации нагрузки все эти данные, как правило, кладутся в NoSQL хранилища или вытягиваются простыми запросами к БД и не строят многоуровневые агрегаты, а используются DTO или вообще массивы.
Домен нужен для того, чтоб сформировать бизнес логику обработки Write потока, а доменные события тригерят обновление кеша и снепшотов для Read потока.
Это мнение Эванса и Вернона и я с ними солидарен. Я не хочу сказать, что все должны делать так, но там где есть выделенный домен, как правило задумываются о разделении read и write потоков.
Грань каждый определяет сам. Есть некоторые рекомендации описанные в книгах по DDD, но четких правил нет.