Брокер сообщений выглядит как узкое место системы. Если генераторов и потребителей событий может быть сколько угодно и их можно масштабировать, то общаются они все через одного брокера. Мало того, брокер может и упасть, что приведёт к полной остановке системы.
Или есть варианты с пулом брокеров?
Создаётся впечатление, что Вы не увидели сути в публикации и критикуете инструмент по визуализации диаграмм баз данных
Я даже не знаю, каким Вы инструментом пользовались, и в данном контексте это вообще не важно.
Услыште меня, я уже устал повторять одно и тоже — Вы неправильно используете нотацию crow foot, в тексте у Вас связь обозначена как обязательная, а на схеме — как необязательная. И эта ошибка повторена неоднократно.
И это может сбить с толку неопытных читателей Вашей статьи (джунов, студентов и т.п.), только поэтому я за этот момент и зацепился. Детей жалко :)
А Вы можете сколько угодно оставаться в мире своих заблуждений. Я бы порекомендовал Вам поразбираться с этой нотацией, но что-то мне подсказывает, что Вы этого делать не захотите.
За сим всё-таки окончательно откланиваюсь, ничего конструктивного Вы так и не сказали (но за SSMS отдельное спасибо, хорошее настроение у меня на весь день обеспечено :)).
Вау, Вы меня впечатлили! )))))
Я, вообще-то, говорил о нотации crow foot (которую Вы использовали в статье).
А то, что SSMS использует какую-то свою, совсем другую — это все знают. Ну, или не все… =D
Не хочу задеть, но у меня сложилось впечатление, что Вы теоретик и оперируете академическими понятиями из ВУЗа, где так много уделялось видам стрелок с кружком и без.
Ошибаетесь, я — практик. И если уж мы тут начали пиписками меряться, то моя нынешняя должность называется "Эксперт по разработке". (А вообще Ваша тирада выглядит странно — наличие большого опыта исключает возможность делать ошибки или заблуждаться?)
И как практик я знаю, что всевозможные схемы (в т.ч. различные схемы БД) служат, в первую очередь, для передачи знаний между членами команды. И если Вы в голове держите "1 или N", а на схеме нарисовали "0 или N", то другой разработчик при имплементации какой вариант реализует, как думаете?
Если Вы мне советуете это почитать, то зря — я как раз-таки понимаю разницу между концептуальной, логической и физической моделями базы данных.
И не могут при переходе между уровнями модели внезапно изменяться свойства связи — мощность, обязательность и т.д.
Поэтому если Вы на концептуальном уровне указали, что на данном конце связи должно быть "ноль или один" — в таком виде это у Вас и доедет до физической модели.
Так что тут Вы опять ошиблись.
И всё равно всё вышесказанное Вами не отменяет того факта, что у Вас в статье схемы не соответствуют тексту. Заканчивайте уже выискивать какие-то странные оправдания в виде размытых фраз.
На всякий случай подытожу — вдруг в будущем эту статью будут читать студенты, надо их предостеречь :) — и больше уже возвращаться не буду.
В нотации crow foot значки и имеют разный смысл, так же, как и и , и в статье много неверных схем в том смысле, что они не соответствуют тексту, например, в тексте речь идёт про обязательность, а на схеме этот конец связи с "ноликом".
В зависимости от потребностей можно выбирать один из правильных вариантов, например, при связи "1:1" хранить всё в одной таблице или в двух связанных.
Какие потребности могут заставить выбрать неправильный вариант, я не представляю.
Делают это для того, чтобы не раздувать таблицу, а также когда например хотят разделить те поля, которые не у всех заполняются (напр, детали сущности).
Как раз при правильной структуре будет меньше полей за счёт того, что связь будет одна.
сложно, но можно.
Если что-то может пойти не так — оно обязательно пойдёт не так.
На предыдущем проекте наелись вот этого самого. В структуре БД не был предусмотрен (нашими предками) контроль консистентности, в результате багов (и ещё неправильных подходов к разработке) накопилось такое огромное количество "мусорных" данных, что решение этой проблемы заняло сотни человеко-часов.
Задавать связь мощности "1:1" через две связи между таблицами нельзя. Тем самым Вы открываете дорогу для возникновения неконсистентного состояния системы.
Пример:
В таблице Citizen есть запись с CitizenID == 42 и PassportID == 999 (пусть это будет некто Иванов).
В таблице PassportData есть запись с PassportID == 999 и CitizenID == 123 (это айдишник Петрова).
Вопрос: кому принадлежит паспорт с айдишником 999 — Иванову или Петрову?
Такое ощущение, что Вы плохо понимаете нотацию crow foot. Есть куча мест, где по тексту связь обязательна, а на схеме — необязательна.
Пример: п.2.1, цитирую: "У каждого родителя есть как минимум один ребенок.". При этом на схеме у таблицы Child значок "от 0 до N", т.е. детей у родителя может и не быть.
В п.2.2, где наличие детей становится необязательным, Вы почему-то сделали необязательным наличие родителя — со стороны таблицы Person изображена мощность "0 или 1".
Ещё пример — 1.1.2. По Вашей схеме у гражданина наличие паспорта необязательно, как и наличие у паспорта гражданина.
И т.д.
Вот Вы привели кратко теорию по DDD — а зачем? При проектировании Вашей системы вы DDD не использовали — я делаю этот вывод на том основании, что при описании процесса проектирования ни разу не были упомянуты ни единый язык, ни ограниченный контекст, ни остальные термины из DDD.
Термин "анемичная модель" встречается в посте один раз — в заголовке. Те, кто знает, что это такое — видят, что в системе именно она и используется. Для тех же, кто не знает, было бы неплохо привести определение и показать, что Ваша система под него подпадает.
Он может и не знать, что результат, который он считает ошибочным — может быть на самом деле верным
Это как вообще? У Вас программисты лепят фичи без спецификации, от ветра головы своея?
При возникновении требования аналитик формализует его в виде спецификации.
Программист в соответствии с этой спецификацией лепит фичу.
Тестировщик проверяет, что творение программиста этой спецификации соответствует. Если видит несоответствие — заводит багу. Аналитик (да, Вы правы, именно он видит общую картину) для этой баги выставляет приоритет и определяет срочность (эта/следующая итерация, бэклог и т.д.)
Аналитик не может без тестировщика завести багу, ну никак. Тестировщик без аналитика — может. Так зачем задействовать двоих там, где можно обойтись одним?
А если ещё не зарелизили?
Программист запилил фичу, перед попаданием на прод она, естественно, проходит разные этапы проверки, в том числе тестировщиком.
Тестировщик обнаружил баг (несоответствие поведения системы спецификации) — либо он может завести баг сразу сам, либо, по Вашей схеме, должен отвлекать аналитика только для того, чтобы тот под диктовку багу завёл?
И всё таки "стандартный текст" бьёт по глазам. По смыслу очень далеко от "текста стандарта".
Брокер сообщений выглядит как узкое место системы. Если генераторов и потребителей событий может быть сколько угодно и их можно масштабировать, то общаются они все через одного брокера. Мало того, брокер может и упасть, что приведёт к полной остановке системы.
Или есть варианты с пулом брокеров?
Понятно, спасибо.
Скажите, пожалуйста, а как вы замеряете Line Coverage только для нового кода?
Я даже не знаю, каким Вы инструментом пользовались, и в данном контексте это вообще не важно.
Услыште меня, я уже устал повторять одно и тоже — Вы неправильно используете нотацию crow foot, в тексте у Вас связь обозначена как обязательная, а на схеме — как необязательная. И эта ошибка повторена неоднократно.
И это может сбить с толку неопытных читателей Вашей статьи (джунов, студентов и т.п.), только поэтому я за этот момент и зацепился. Детей жалко :)
А Вы можете сколько угодно оставаться в мире своих заблуждений. Я бы порекомендовал Вам поразбираться с этой нотацией, но что-то мне подсказывает, что Вы этого делать не захотите.
За сим всё-таки окончательно откланиваюсь, ничего конструктивного Вы так и не сказали (но за SSMS отдельное спасибо, хорошее настроение у меня на весь день обеспечено :)).
Вау, Вы меня впечатлили! )))))
Я, вообще-то, говорил о нотации crow foot (которую Вы использовали в статье).
А то, что SSMS использует какую-то свою, совсем другую — это все знают. Ну, или не все… =D
Ошибаетесь, я — практик. И если уж мы тут начали пиписками меряться, то моя нынешняя должность называется "Эксперт по разработке". (А вообще Ваша тирада выглядит странно — наличие большого опыта исключает возможность делать ошибки или заблуждаться?)
И как практик я знаю, что всевозможные схемы (в т.ч. различные схемы БД) служат, в первую очередь, для передачи знаний между членами команды. И если Вы в голове держите "1 или N", а на схеме нарисовали "0 или N", то другой разработчик при имплементации какой вариант реализует, как думаете?
Если Вы мне советуете это почитать, то зря — я как раз-таки понимаю разницу между концептуальной, логической и физической моделями базы данных.
И не могут при переходе между уровнями модели внезапно изменяться свойства связи — мощность, обязательность и т.д.
Поэтому если Вы на концептуальном уровне указали, что на данном конце связи должно быть "ноль или один" — в таком виде это у Вас и доедет до физической модели.
Так что тут Вы опять ошиблись.
И всё равно всё вышесказанное Вами не отменяет того факта, что у Вас в статье схемы не соответствуют тексту. Заканчивайте уже выискивать какие-то странные оправдания в виде размытых фраз.
На всякий случай подытожу — вдруг в будущем эту статью будут читать студенты, надо их предостеречь :) — и больше уже возвращаться не буду.
и 
имеют разный смысл, так же, как и 
и 
, и в статье много неверных схем в том смысле, что они не соответствуют тексту, например, в тексте речь идёт про обязательность, а на схеме этот конец связи с "ноликом".
В нотации crow foot значки
В том-то и дело, что у Вас схема 2.1.2 выглядит так:
Именно это я и пытаюсь до Вас донести.
В зависимости от потребностей можно выбирать один из правильных вариантов, например, при связи "1:1" хранить всё в одной таблице или в двух связанных.
Какие потребности могут заставить выбрать неправильный вариант, я не представляю.
Не совсем понимаю, как проблема с несобираемыми данными связана с неправильной в данном конкретно случае структурой БД.
Нет, не правильно.
Если, как у Вас написано, "У каждого родителя есть как минимум один ребенок.", то связь должна выглядеть вот так:
Как раз при правильной структуре будет меньше полей за счёт того, что связь будет одна.
Если что-то может пойти не так — оно обязательно пойдёт не так.
На предыдущем проекте наелись вот этого самого. В структуре БД не был предусмотрен (нашими предками) контроль консистентности, в результате багов (и ещё неправильных подходов к разработке) накопилось такое огромное количество "мусорных" данных, что решение этой проблемы заняло сотни человеко-часов.
Задавать связь мощности "1:1" через две связи между таблицами нельзя. Тем самым Вы открываете дорогу для возникновения неконсистентного состояния системы.
Пример:
Вопрос: кому принадлежит паспорт с айдишником 999 — Иванову или Петрову?
Такое ощущение, что Вы плохо понимаете нотацию crow foot. Есть куча мест, где по тексту связь обязательна, а на схеме — необязательна.
Пример: п.2.1, цитирую: "У каждого родителя есть как минимум один ребенок.". При этом на схеме у таблицы Child значок "от 0 до N", т.е. детей у родителя может и не быть.
В п.2.2, где наличие детей становится необязательным, Вы почему-то сделали необязательным наличие родителя — со стороны таблицы Person изображена мощность "0 или 1".
Ещё пример — 1.1.2. По Вашей схеме у гражданина наличие паспорта необязательно, как и наличие у паспорта гражданина.
И т.д.
Это как вообще? У Вас программисты лепят фичи без спецификации, от ветра головы своея?
Аналитик не может без тестировщика завести багу, ну никак. Тестировщик без аналитика — может. Так зачем задействовать двоих там, где можно обойтись одним?
А если ещё не зарелизили?
Программист запилил фичу, перед попаданием на прод она, естественно, проходит разные этапы проверки, в том числе тестировщиком.
Тестировщик обнаружил баг (несоответствие поведения системы спецификации) — либо он может завести баг сразу сам, либо, по Вашей схеме, должен отвлекать аналитика только для того, чтобы тот под диктовку багу завёл?
Спасибо!