Но это как-то не отвечает на Ваше же собственный комментарий, что нельзя совмещать DDD и микросервисы. Пока что Ваши доводы говорят как раз об обратном - что можно это делать. Как так?
Отдельно стоит сказать про отладку - как раз она становится в разы более легкой.
А всё остальное довольно хорошо решается документированием , которое для простых микросервисов выглядит гораздо проще для понимания. В сочетании с луковой архитектурой изучить документацию становится легко
Хороший подход, но я бы добавил сюда еще и личные интервью с сотрудниками, потому что в беседах часто оказывается, что есть прямо-таки "горящие" проблемы, про которые все думают и держат в голове, но мало кто говорит. Просто из личной практики проведения интервью
Дело в том, что я не искал метафору в статье, а описал выводы, которые сделал из собственной практики, когда на себе попробовал микросервисы со многими сущностями и сравнил их с микросервисом из одного агрегата. Как говориться, tremendous difference. Думаю, что все возражения к статье сводятся к тому, что большинство людей воспринимает DDD как отстраненную теорию, хотя она, на самом деле, самая что ни на есть практическая инструкция к действию. Но пока не попробуешь на себе - не узнаешь, работает ли предложенный в статье подход или нет.
Каких именно сущностей и почему много? В этом весь вопрос. И не превратится ли это "много" в очередную монструозную систему на базе кубера, как это, в основном, и происходит?
Если попробовать применить DDD на практике, то становится понятным, что само понятие домена - чисто информационная вещь, которую особо никак не используешь. В реальности очень многие сущности предметной области (ограниченные контексты) могут входить (и входят) сразу в несколько доменов. А если сделать следующий шаг и подумать над ПРАКТИЧЕСКОЙ целью DDD, то становится очевидным, что концепция создавалась в первую очередь для упрощения микросервисной архитектуры
Вероятно, каждый понимает её по своему, но если почитать синюю и красную книги, то там речь идет именно о системах/микросервисах, скрывающихся под ограниченными контекстами. Более того, в книгах огромные разделы посвящены именно построению микросервисов на основе DDD
Самое сложное тут, с моей точки зрения, как раз скрывается в A, B, C. Вообще не очевидно как правильно их формулировать, а если общая цель не будет ясной и единой, то и всё остальное рассыплется как карточный домик. Ключевое тут: "Если ..., то..." и "При условии, что ...". Цель А выполняется "при условии, что ..." выполняются B и C.
Использую подобную систему и уже долгое время. Из инструментария понравился workflowy.com - в нём можно не только списки выгрузить из головы, но и делать канбан доски на любом уровне вложения
Великолепная статья. Подписываюсь под каждым словом. Честность и открытость в компаниях - это критический компонент. Если его нет, то движение идёт в обратную сторону
С большими сценариями помогает их разбитие на "пользовательские истории" (в моей интерпретации). Это когда под историей понимается один конкретный альтернативный путь из большого сценария.
Пример из нашей практики.
Большой сценарий: выдача груза Водителем на точке доставки
Основной путь (пользовательская история): Получатель груза на месте и он принимает груз оптом (просто пересчитывая грузовые места)
Альтернативный путь (пользовательская история): Получатель решает принять груз по-коробочно (сверяя номер на этикетке каждой коробки)
Альтернативный путь (пользовательская история): Получателя нет на месте, Водитель отменяет доставку
Альтернативный путь (пользовательская история): Получателя нет на месте, но вместе него получает другой человек.
и т.п.
В таком варианте "истории" получаются не очень большими и вполне помещаются в спринт. И их даже можно выводить по-отдельности в прод.
Точно. И это хорошо
Но это как-то не отвечает на Ваше же собственный комментарий, что нельзя совмещать DDD и микросервисы. Пока что Ваши доводы говорят как раз об обратном - что можно это делать. Как так?
Где легче найти ошибку, в коде из 1000 строк или в коде из 10 строк? С микросервисами буквально также
Да, смотрится сложно. Хороший опыт восприятия такой структуры даёт работы в компаниях типа Сбера. После него всё кажется таким простым :-)
Очень просто: сами микросервисы становятся меньше по объему кода и функционала. И их легче отлаживать
Отдельно стоит сказать про отладку - как раз она становится в разы более легкой.
А всё остальное довольно хорошо решается документированием , которое для простых микросервисов выглядит гораздо проще для понимания. В сочетании с луковой архитектурой изучить документацию становится легко
Хороший подход, но я бы добавил сюда еще и личные интервью с сотрудниками, потому что в беседах часто оказывается, что есть прямо-таки "горящие" проблемы, про которые все думают и держат в голове, но мало кто говорит. Просто из личной практики проведения интервью
Усугубляются, конечно. CAP-теорему никто не отменял. Но выгоды, с моей точки зрения, перетягивают
У Вас отрицательный опыт работы с микросервисами? Что с ними не так и почему DDD не надо лепить к микросервисам?
Главное, чтобы это не было т.н. "ложным убеждением". На основании чего Вы это утверждаете?
Просто попробуйте представить, что ситуация может быть как раз обратной.
Все остальные доводы в ответе следуют из первого утверждения, как я понимаю.
Дело в том, что я не искал метафору в статье, а описал выводы, которые сделал из собственной практики, когда на себе попробовал микросервисы со многими сущностями и сравнил их с микросервисом из одного агрегата. Как говориться, tremendous difference. Думаю, что все возражения к статье сводятся к тому, что большинство людей воспринимает DDD как отстраненную теорию, хотя она, на самом деле, самая что ни на есть практическая инструкция к действию. Но пока не попробуешь на себе - не узнаешь, работает ли предложенный в статье подход или нет.
Каких именно сущностей и почему много? В этом весь вопрос. И не превратится ли это "много" в очередную монструозную систему на базе кубера, как это, в основном, и происходит?
и какой отсюда вывод? Что такое, на Ваш взгляд, ограниченный контекст?
Если попробовать применить DDD на практике, то становится понятным, что само понятие домена - чисто информационная вещь, которую особо никак не используешь. В реальности очень многие сущности предметной области (ограниченные контексты) могут входить (и входят) сразу в несколько доменов. А если сделать следующий шаг и подумать над ПРАКТИЧЕСКОЙ целью DDD, то становится очевидным, что концепция создавалась в первую очередь для упрощения микросервисной архитектуры
А есть разница?
Вероятно, каждый понимает её по своему, но если почитать синюю и красную книги, то там речь идет именно о системах/микросервисах, скрывающихся под ограниченными контекстами. Более того, в книгах огромные разделы посвящены именно построению микросервисов на основе DDD
Самое сложное тут, с моей точки зрения, как раз скрывается в A, B, C. Вообще не очевидно как правильно их формулировать, а если общая цель не будет ясной и единой, то и всё остальное рассыплется как карточный домик. Ключевое тут: "Если ..., то..." и "При условии, что ...". Цель А выполняется "при условии, что ..." выполняются B и C.
Использую подобную систему и уже долгое время. Из инструментария понравился workflowy.com - в нём можно не только списки выгрузить из головы, но и делать канбан доски на любом уровне вложения
Великолепная статья. Подписываюсь под каждым словом. Честность и открытость в компаниях - это критический компонент. Если его нет, то движение идёт в обратную сторону
С большими сценариями помогает их разбитие на "пользовательские истории" (в моей интерпретации). Это когда под историей понимается один конкретный альтернативный путь из большого сценария.
Пример из нашей практики.
Большой сценарий: выдача груза Водителем на точке доставки
Основной путь (пользовательская история): Получатель груза на месте и он принимает груз оптом (просто пересчитывая грузовые места)
Альтернативный путь (пользовательская история): Получатель решает принять груз по-коробочно (сверяя номер на этикетке каждой коробки)
Альтернативный путь (пользовательская история): Получателя нет на месте, Водитель отменяет доставку
Альтернативный путь (пользовательская история): Получателя нет на месте, но вместе него получает другой человек.
и т.п.
В таком варианте "истории" получаются не очень большими и вполне помещаются в спринт. И их даже можно выводить по-отдельности в прод.