Монолит - это одно приложение со связанным контекстом и типами.
Микросервисы - это отдельные приложения, не связанные ничем, кроме сетевого апи.
И то и другое может быть хреново написанное. Только у монолит сложнее писать, потому что он требует связность взаимодействия между частями. Поменял одну часть - остальное не скомпилится, пока не привёл в соответствие всех связанных.
Микросервисы проще писать, потому что они ни от кого не зависят. Зато потом вскрывается это "не зависит". Оказывается, что зависит, и ещё как. Но уже в рантайме.
Это не я свёл к бюджету. Это вы. Это вы сказали, что в айти только к срокам и бюджетам риски сводятся. Они точно так же к рискам и бюджету сводятся, как и у бизнеса, даже просто потому, что айти - часть бизнеса.
Вопрос: а зачем все эти пафосные речи? Зачем пренебрежение к айтишным рискам, которые существуют и находятся с нами в одной комнате?
И это победитель нашей сегодняшней викторины!!! Правильно!
После запрета вацапа аудитория преимущественно переползёт в телеграм. Наверное слухи о том, что Паша договаривается с правительством не беспочвенны. Жаль, что потом отрубят и телеграм.
Риски ведения любого реального бизнеса, связанного с физическими объектами и живыми людьми несоизмеримо выше любой разработки, поэтому даже заикаться о рисках в ИТ, что чего‑то там «возможно не получится» — откровенно смешно.
Не смешно. Надо разделять вероятность риска и влияние плохого результата на дальнейшую деятельность. Риски в айти - непредсказуемые, огромные по вероятности и нарастающие вместе со сложностью проекта. Попробуйте найти большой проект без просранных сроков.
Влияние в деньгах на бизнес выше, это правда. Но это компенсируется прибыльностью бизнеса. Бизнес не будет делиться неожиданно высокой прибыльностью с линейным программером, он заберёт всё себе. Как следствие - он не в праве штрафовать программера, если у него появилась куча подводных камней. Да и вообще, программер обещал менять часы работы на деньги, а не впахивать на успех бизнеса.
Еще раз: ни одна предметная область не является "фиксированной"
Ни одно приложение не является "фиксированным". Более того, люди постоянно развивают свои приложения, обрабатывая новые процессы, объективно имеющиеся в предметной области, но до сих пор скрытых.
Прикол в том, что если задумаете убрать бардак (то есть бороться со сложностью), то вы захотите отделить изменчивую бизнес-логику от каркаса приложения. Просто потому что так будет намного легче читать и дорабатывать бизнес-код.
Потом вы захотите эту бизнес-логику типизировать по названиям, чтобы с бизнесом говорить на одном языке. И ещё сделаете иерархию доменных сущностей как в бизнес-процессах. Но доменными сущностями вы их всё равно не будете называть.
А потом покажете людям и скажете: смотрите, я навёл порядок не используя DDD!
Мне останется только усмехнуться тихонечко в стороне. Я же уже это проходил. Конечно, вы не использовали DDD. Вы его породили.
Противоречит. Автор пишет, что распределённый монолит - это ад. А я считаю, что микросервисы - ад и у меня есть веские основания так считать. А распределённый монолит считаю просто нормальной архитектурой, где нет вышеописанных недостатков и позаботились об разделении обязанностей блоков кода. Впрочем, при нормальной архитектуре монолит будет ещё и модульным и тогда требующие распределения части легко вынести в отдельные сервисы. Не микро.
Почему хоть кто-то из DDDшников не может написать проект, который читатели могут посмотреть и ответить для себя: да оно работает или нет, оно приносит больше сложностей чем решает и нежизнеспособно?
Потому что DDD - это не фреймворк. Это принцип. И проект, который сделан по принципу DDD будет снижать сложность конкретной области и не применим в другой. Причём если вы посмотрите на проект, вы не увидите снижения сложности. Для того, чтобы её увидеть, нужно взять два проекта: один в бардаке, второй после рефакторинга по DDD.
Разбиение системы на микросервисы без учёта всего вышесказанного – прямая дорога в ад распределённого монолита, который объединяет все худшие качества монолита со всеми худшими качествами микросервисов
Категорически не согласен. Недостатки микросервисов - в мокром коде (not DRY), катастрофических потерях на сетевое взаимодействие, сериализация/десериализация сообщений с потерей типизации аргументов, ловля ошибок через сеть и веселье с деплоем/оркерстрацией всего этого праздника.
Да, DDD - это инструмент управления сложностью. Эта мысль верная и только за это я поставил плюсик статье. Эту мысль нужно озвучивать.
Вот только DDD управляет сложностью не микросервисами. Ему всё равно, на чём вы сделаете разделение обязанностей. Главное, чтобы у вас части были логически отделены друг от друга, чтобы у них были чёткие обязанности. Это прекрасно делается в монолите, если руки не из жопы.
Да я понимаю. Сам же ещё в 2008м году что-то подобное делал и упорно не хотел называть это ORM. Там сильно проще было, в угоду времени, но с кодогенерацией по структуре БД.
А так у вас уже есть маппер, можно прикрутить кодогенерацию по структуре (или модели) и немного расширить возможность составления запросов. Если linq прикрутить, так вообще будет весь EF...
Странно, конечно, что тут вообще DataTable делает. Можно же сразу из ридера грузить без посредников.
а для подвоза результата к сроку, на который босс забился с заказчиком
А ещё если босс пообещал конкретный срок заказчику - это проблемы самого босса. Даже если вы сами сказали ему эту дату.
Потому что разработка - это не упаковка конфет на конвейере со строго регламентированной скоростью. Тут каждая задача - уникальна. И в каждой попадаются свои подводные камни. И чем больше задача - тем больше в ней встречаются камушки.
Если босс не знает про специфику разработки - это его проблемы. Если он пытается перевесить свои договорённости на вас - это его проблемы. Вы продаёте своё время за его деньги, о чём и был трудовой договор.
Риски не успеть - это риски босса. Это он владеет бизнесом, он управляет обещаниями клиентам, он управляет методами решения этих проблем. Он ДОЛЖЕН разбираться в специфике работы своих сотрудников. Он ДОЛЖЕН брать риски на себя и понимать, чем он рискует.
ммм... нет.
Монолит - это одно приложение со связанным контекстом и типами.
Микросервисы - это отдельные приложения, не связанные ничем, кроме сетевого апи.
И то и другое может быть хреново написанное. Только у монолит сложнее писать, потому что он требует связность взаимодействия между частями. Поменял одну часть - остальное не скомпилится, пока не привёл в соответствие всех связанных.
Микросервисы проще писать, потому что они ни от кого не зависят. Зато потом вскрывается это "не зависит". Оказывается, что зависит, и ещё как. Но уже в рантайме.
Ага, только нового каскадёра обучать - это дни. А вот нового лида вкурить в курс дела - год. При большом проекте.
Вы там переживёте оцепление, надо будет - постановщика найдёте нового.
Я не понимаю вот чего: а зачем вы так пренебрежительно относитесь к рискам в айти?
Зачем опять вы переходите на личности? В прошлый раз мы мне советовали обратиться к лечащему врачу. Зачем так?
Может быть это вы далеки от реальности айтишной и не понимаете, что тут риски не меньше по амплитуде?
Окей, верно. Но я не про это спрашивал. В чём разница для проекта?
Замена каскадёра тогда тоже не повлияет.
В чём разница?
А, то есть лид проекта не может попасть под автобус, да?
Бюджет
Сроки, возможно бюджет
Это не я свёл к бюджету. Это вы. Это вы сказали, что в айти только к срокам и бюджетам риски сводятся. Они точно так же к рискам и бюджету сводятся, как и у бизнеса, даже просто потому, что айти - часть бизнеса.
Вопрос: а зачем все эти пафосные речи? Зачем пренебрежение к айтишным рискам, которые существуют и находятся с нами в одной комнате?
Например я. Что это меняет в области рисков?
То же, что и все остальные - страховать.
А что, бывают другие риски, кроме сроков и бюджета?
Ну давайте, расскажите про риски бизнеса, которые не в бюджет и не в сроки упираются.
И это победитель нашей сегодняшней викторины!!! Правильно!
После запрета вацапа аудитория преимущественно переползёт в телеграм. Наверное слухи о том, что Паша договаривается с правительством не беспочвенны. Жаль, что потом отрубят и телеграм.
Не смешно. Надо разделять вероятность риска и влияние плохого результата на дальнейшую деятельность. Риски в айти - непредсказуемые, огромные по вероятности и нарастающие вместе со сложностью проекта. Попробуйте найти большой проект без просранных сроков.
Влияние в деньгах на бизнес выше, это правда. Но это компенсируется прибыльностью бизнеса. Бизнес не будет делиться неожиданно высокой прибыльностью с линейным программером, он заберёт всё себе. Как следствие - он не в праве штрафовать программера, если у него появилась куча подводных камней. Да и вообще, программер обещал менять часы работы на деньги, а не впахивать на успех бизнеса.
Ни одно приложение не является "фиксированным". Более того, люди постоянно развивают свои приложения, обрабатывая новые процессы, объективно имеющиеся в предметной области, но до сих пор скрытых.
Прикол в том, что если задумаете убрать бардак (то есть бороться со сложностью), то вы захотите отделить изменчивую бизнес-логику от каркаса приложения. Просто потому что так будет намного легче читать и дорабатывать бизнес-код.
Потом вы захотите эту бизнес-логику типизировать по названиям, чтобы с бизнесом говорить на одном языке. И ещё сделаете иерархию доменных сущностей как в бизнес-процессах. Но доменными сущностями вы их всё равно не будете называть.
А потом покажете людям и скажете: смотрите, я навёл порядок не используя DDD!
Мне останется только усмехнуться тихонечко в стороне. Я же уже это проходил. Конечно, вы не использовали DDD. Вы его породили.
Противоречит. Автор пишет, что распределённый монолит - это ад. А я считаю, что микросервисы - ад и у меня есть веские основания так считать. А распределённый монолит считаю просто нормальной архитектурой, где нет вышеописанных недостатков и позаботились об разделении обязанностей блоков кода. Впрочем, при нормальной архитектуре монолит будет ещё и модульным и тогда требующие распределения части легко вынести в отдельные сервисы. Не микро.
Потому что DDD - это не фреймворк. Это принцип. И проект, который сделан по принципу DDD будет снижать сложность конкретной области и не применим в другой. Причём если вы посмотрите на проект, вы не увидите снижения сложности. Для того, чтобы её увидеть, нужно взять два проекта: один в бардаке, второй после рефакторинга по DDD.
Категорически не согласен. Недостатки микросервисов - в мокром коде (not DRY), катастрофических потерях на сетевое взаимодействие, сериализация/десериализация сообщений с потерей типизации аргументов, ловля ошибок через сеть и веселье с деплоем/оркерстрацией всего этого праздника.
Да, DDD - это инструмент управления сложностью. Эта мысль верная и только за это я поставил плюсик статье. Эту мысль нужно озвучивать.
Вот только DDD управляет сложностью не микросервисами. Ему всё равно, на чём вы сделаете разделение обязанностей. Главное, чтобы у вас части были логически отделены друг от друга, чтобы у них были чёткие обязанности. Это прекрасно делается в монолите, если руки не из жопы.
лол
Да я понимаю. Сам же ещё в 2008м году что-то подобное делал и упорно не хотел называть это ORM. Там сильно проще было, в угоду времени, но с кодогенерацией по структуре БД.
А так у вас уже есть маппер, можно прикрутить кодогенерацию по структуре (или модели) и немного расширить возможность составления запросов. Если linq прикрутить, так вообще будет весь EF...
Странно, конечно, что тут вообще DataTable делает. Можно же сразу из ридера грузить без посредников.
То есть между реляционными рядами RDBMS и объектами языка с ООП?
А Object-Relational Mapper назвать можно?
Так это же ORM. Да, не полный, да самописный, но это уже ORM.
А ещё если босс пообещал конкретный срок заказчику - это проблемы самого босса. Даже если вы сами сказали ему эту дату.
Потому что разработка - это не упаковка конфет на конвейере со строго регламентированной скоростью. Тут каждая задача - уникальна. И в каждой попадаются свои подводные камни. И чем больше задача - тем больше в ней встречаются камушки.
Если босс не знает про специфику разработки - это его проблемы. Если он пытается перевесить свои договорённости на вас - это его проблемы. Вы продаёте своё время за его деньги, о чём и был трудовой договор.
Риски не успеть - это риски босса. Это он владеет бизнесом, он управляет обещаниями клиентам, он управляет методами решения этих проблем. Он ДОЛЖЕН разбираться в специфике работы своих сотрудников. Он ДОЛЖЕН брать риски на себя и понимать, чем он рискует.