Вроде как Сулуэт и Лук наоборот показывают на Вашем графике, что кластеризация не состоялась, что подтверждает и вид кластеров. Что-то у Вас не то, судя по всему. На кластеризацию очень сильно влияет набор фич. Стоит с ним поработать
Наверное я просто не встречался с ненужными сложностями. И логика вроде как изначально отделена от инфраструктуры. По крайней мере луковая архитектура вполне себе позволяет это сделать. Про кучу абстракций вообще интересно где нашли. Т.е. в целом складывается впечатление скорее о каком-то странном использовании ddd.
Буквально на днях общался с коллегой, который прошёл курсы Яндекса по ddd. Когда я рассказал ему своё понимание DDD и мы совместно расписали его примеры, он выпал в осадок насколько все по-другому.
Поэтому и говорю, что тут скорее похоже на недостаточное изучение темы
Из практики вижу, что лучшее сразу делить на микросервисы. Основные преимущества лично для меня: микросервисы получаются небольшими и их очень просто сопровождать и дорабатывать. Они изначально получаются автономными, т.е. работают в асинхронном режиме. Ну и огромный плюс - понятия бизнес области = микросервисам, что очень сильно облегчает понимание и проектирование бизнесовых процессов. Единственное, что приходится делать - аккуратно вести архитектуру. Использую для этого PlantUML и возможности его препроцессора.
С моей точки зрения люди находятся в плену своего видения. Если один раз столкнулся с проблемой микросервисов, то начинаешь думать, что все микросервисы это лажа. Однако вероятно, что проблема с микроскопами возникла именно из-за их неправильного выделения и непонимания как их лучше использовать
Но это как-то не отвечает на Ваше же собственный комментарий, что нельзя совмещать DDD и микросервисы. Пока что Ваши доводы говорят как раз об обратном - что можно это делать. Как так?
Отдельно стоит сказать про отладку - как раз она становится в разы более легкой.
А всё остальное довольно хорошо решается документированием , которое для простых микросервисов выглядит гораздо проще для понимания. В сочетании с луковой архитектурой изучить документацию становится легко
Хороший подход, но я бы добавил сюда еще и личные интервью с сотрудниками, потому что в беседах часто оказывается, что есть прямо-таки "горящие" проблемы, про которые все думают и держат в голове, но мало кто говорит. Просто из личной практики проведения интервью
Дело в том, что я не искал метафору в статье, а описал выводы, которые сделал из собственной практики, когда на себе попробовал микросервисы со многими сущностями и сравнил их с микросервисом из одного агрегата. Как говориться, tremendous difference. Думаю, что все возражения к статье сводятся к тому, что большинство людей воспринимает DDD как отстраненную теорию, хотя она, на самом деле, самая что ни на есть практическая инструкция к действию. Но пока не попробуешь на себе - не узнаешь, работает ли предложенный в статье подход или нет.
Вроде как Сулуэт и Лук наоборот показывают на Вашем графике, что кластеризация не состоялась, что подтверждает и вид кластеров. Что-то у Вас не то, судя по всему. На кластеризацию очень сильно влияет набор фич. Стоит с ним поработать
Каждый имеет право думать так как он хочет, верно? И делают все по-разному. Кто-то работает по ТЗ, а кто-то давно уже нет.
Не совсем понял в чем именно бред
А зачем вам домены? Вы как-то их используете? Почему с доменами такой принципиальный вопрос?
Наверное я просто не встречался с ненужными сложностями. И логика вроде как изначально отделена от инфраструктуры. По крайней мере луковая архитектура вполне себе позволяет это сделать. Про кучу абстракций вообще интересно где нашли. Т.е. в целом складывается впечатление скорее о каком-то странном использовании ddd.
Буквально на днях общался с коллегой, который прошёл курсы Яндекса по ddd. Когда я рассказал ему своё понимание DDD и мы совместно расписали его примеры, он выпал в осадок насколько все по-другому.
Поэтому и говорю, что тут скорее похоже на недостаточное изучение темы
Из практики вижу, что лучшее сразу делить на микросервисы. Основные преимущества лично для меня: микросервисы получаются небольшими и их очень просто сопровождать и дорабатывать. Они изначально получаются автономными, т.е. работают в асинхронном режиме. Ну и огромный плюс - понятия бизнес области = микросервисам, что очень сильно облегчает понимание и проектирование бизнесовых процессов. Единственное, что приходится делать - аккуратно вести архитектуру. Использую для этого PlantUML и возможности его препроцессора.
Ограниченный контекст это понятие скорее семантическое. Просто его вполне хорошо себе можно использовать для выполнения микросервисов
С моей точки зрения люди находятся в плену своего видения. Если один раз столкнулся с проблемой микросервисов, то начинаешь думать, что все микросервисы это лажа. Однако вероятно, что проблема с микроскопами возникла именно из-за их неправильного выделения и непонимания как их лучше использовать
Отличная статья. Большое спасибо. Делаю микросервис примерно такую же тему, но только разрезе по складам и кластерам - своей статьей Вы помогли.
Не совсем понял вопрос, но скорее нет, чем да. Понятие "должен" тут тоже не применимо
Точно. И это хорошо
Но это как-то не отвечает на Ваше же собственный комментарий, что нельзя совмещать DDD и микросервисы. Пока что Ваши доводы говорят как раз об обратном - что можно это делать. Как так?
Где легче найти ошибку, в коде из 1000 строк или в коде из 10 строк? С микросервисами буквально также
Да, смотрится сложно. Хороший опыт восприятия такой структуры даёт работы в компаниях типа Сбера. После него всё кажется таким простым :-)
Очень просто: сами микросервисы становятся меньше по объему кода и функционала. И их легче отлаживать
Отдельно стоит сказать про отладку - как раз она становится в разы более легкой.
А всё остальное довольно хорошо решается документированием , которое для простых микросервисов выглядит гораздо проще для понимания. В сочетании с луковой архитектурой изучить документацию становится легко
Хороший подход, но я бы добавил сюда еще и личные интервью с сотрудниками, потому что в беседах часто оказывается, что есть прямо-таки "горящие" проблемы, про которые все думают и держат в голове, но мало кто говорит. Просто из личной практики проведения интервью
Усугубляются, конечно. CAP-теорему никто не отменял. Но выгоды, с моей точки зрения, перетягивают
У Вас отрицательный опыт работы с микросервисами? Что с ними не так и почему DDD не надо лепить к микросервисам?
Главное, чтобы это не было т.н. "ложным убеждением". На основании чего Вы это утверждаете?
Просто попробуйте представить, что ситуация может быть как раз обратной.
Все остальные доводы в ответе следуют из первого утверждения, как я понимаю.
Дело в том, что я не искал метафору в статье, а описал выводы, которые сделал из собственной практики, когда на себе попробовал микросервисы со многими сущностями и сравнил их с микросервисом из одного агрегата. Как говориться, tremendous difference. Думаю, что все возражения к статье сводятся к тому, что большинство людей воспринимает DDD как отстраненную теорию, хотя она, на самом деле, самая что ни на есть практическая инструкция к действию. Но пока не попробуешь на себе - не узнаешь, работает ли предложенный в статье подход или нет.