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