Посмотрел прохождения на ютубе. На плейтест не подписывался - лучше не буду портить впечатление багами, дождусь релиза (там, скорее всего, багов на меня ещё оставят ☺).
Есть мнение, что в момент, когда на коллекцию навешивается бизнес-требование (уникальные заголовки, например), она перестаёт быть "generic" и вполне может быть представлена как агрегат. Потому что если нет, то где тогда описывать данное бизнес-правило?
А ещё данные в БД могут за это время измениться. Потому что сервер параллельно обрабатывает много запросов и таких серверов одновременно работает больше одного. А блокировать нельзя, потому что встанет колом вообще вся система.
Сама концепция наличия в памяти полной модели данных (даже если часть этих данных на самом деле не в памяти а будет магически подгружена ORM при обращении) для обеспечения консистентности этих данных была актуальна в то время и для тех технологий, когда появился DDD - а это более 20 лет назад! Этот поезд давно ушёл. Для современных проектов это совершенно нетипичная и малореалистичная картина.
Микросервис, отвечающий за уникальность заголовков - это же считается норм решение, не нарушающее всякие изоляции, верно? Ну вот и воспринимайте PostgreSQL не тупым хранилищем а таким микросервисом, который следит за уникальностью заголовков, вместо того, чтобы страдать из-за "ой, у нас бизнес-правило из кода домена протекло в схему БД". Просто проверка в бизнес-логике данного правила выполняется не поиском по списку всех заголовков в памяти а попыткой сохранить сущность в БД.
Но… это будет уже не DDD, верно? Потому что DDD ставит задачу написать бизнес-логику так, чтобы её мог прочитать и проверить не программист, а бизнес-заказчик. И тут кусок бизнес-логики оказавшийся очень далеко от изучаемого бизнес-заказчиком кода - аж в схеме БД, - никак не вписывается. Но как часто бизнес-заказчики (не являющиеся программистами) реально читают код бизнес-логики написанный идеально по DDD? Я вот о таком в реальных проектах не слышал в принципе, а Вы? А программист, честно, уж как-нибудь переживёт тот факт, что некоторые элементы бизнес-логики ему нужно смотреть не в этом файле с кодом а в соседнем файле со схемой БД. Программист нуждается в DDD чтобы реально сложную бизнес-логику было возможно загрузить в голову, понять, и корректно изменить - и для этого 100% идеальное следование всем требованиям тактики DDD не требуется, особенно когда из-за попытки делать идеальный DDD общая сложность только вырастает, производительность падает, и появляются новые вызовы - вроде необходимости корректно реализовывать и поддерживать логику компенсации саг.
Удивительное дело, всегда когда агитируют за использование тактики DDD почему-то в статьях и примерах кода забывают упомянуть вопросы работы с транзакциями, выбора границ агрегатов и подходы к обеспечиванию консистентности между разными сервисами и даже разными агрегатами в рамках одного сервиса. А это очень важный (на мой взгляд даже ключевой) момент в тактической части DDD: Пиррова победа Domain-Driven Design.
Мне не известны надежные свидетельства того, что описанные в первой части идеи достоверно делают разработку проще, дешевле или приятнее.
С этим помогает отказ от религиозного следования догмам. Тактическое DDD - это очень дорогое удовольствие, и нет никакого смысла платить эту цену в 95% сервисов где просто нет настолько сложной бизнес-логики. Никакое "единообразие архитектуры проекта" не стоит этой цены! Поэтому стоит использовать в абсолютном большинстве сервисов Transaction Script (разумеется, плюс гексагональную), и прибегать к тактическому DDD только в тех сервисах, где сложность бизнес-логики действительно на порядок выше средней.
Могу предположить, что бы ответил автор поста: "человек на собственном проде 4 года зависимости не обновляет! Кошмар, что же он будет вытворять на проде компании!!!" ;-)
Плюсы - это ещё мелочи. Гораздо хуже то, что многие сайты вообще разрешают регистрировать почту только на доменах крупных провайдеров вроде gmail/yandex. Объясняют они это тем, что мол этот крупняк уже верифицировал юзера, собрал телефоны/капчи, а, значит, можно быть уверенным в том, что это не бот а реальный живой человек (да, author.today, я смотрю в т.ч. на тебя!). Очевидно, что они этим по сути убивают федеративность почты. А вы тут про плюсы плачете…
А смысл? Можно подумать есть примеры, когда суды позволяли решить подобные проблемы (конкретно в РФ и конкретно в последние лет 10). Тут на хабре иногда мелькают статьи пары энтузиастов, которые пытаются что-то в этом направлении делать - но прогресса у них я что-то не припомню. Т.е. писать бумажки можно, и деньги на юриста тратить тоже можно, а вот что-то получить взамен кроме формальных отписок и диких (с точки зрения здравого смысла) решений судов - нет.
А по-моему передёргиваете понятия как раз Вы. Потому что когда домашний пользователь, не ИТшник, начинает настраивать на домашнем роутере VPN, обычно по инструкции которую он толком не понимает, то делает он это исключительно для восстановления доступа к информации, которой привык пользоваться.
Иными словами, технически может Вы и правы, но практически это не имеет значения - все домашние VPN делаются как раз для обхода блокировок, поэтому все попадут под новый закон.
Конечно "хороший архитект" и тут зарешает, но на всех таких не напасёшься.
Это правда, но с этим ничего не поделаешь. Суть микросервисной архитектуры в том, что часть сложности переносится из кода в связи между микросервисами. Это позволяет снизить требования к квалификации разработчиков (которых много) за счёт повышения требований к квалификации архитектов (которых мало). Обычно такой размен бизнесу выгоден. Но только при наличии архитекта, который сможет справиться с повысившейся сложностью лично его работы.
А когда этот же UI элемент генерирует бэк что, источников данных становится меньше? Чтобы бэк мог ответить и забыть на нём много всего сделано, чтобы данные из этих разных источников попали в нужном виде в ту БД, из которой бэк "просто ответит и забудет". Всё это - вопрос архитектуры, не больше и не меньше. А когда на архитектуру забили, то и получается "всё переплетено". Это не специфика фронта, это специфика разработки без архитектуры, на бэке так тоже умеют делать.
У вас есть машинка с известной цпу и оперативкой, вот что у вас есть.
Не-а. Не "есть". Мы на бэке её себе искусственно организуем (через контейнеры докер). И делаем это как раз потому, что иначе будет куча лишних сложностей. Это как раз один из тех подходов, о которых я говорил, вместе с фиксированным набором разных типов БД и т.п.
Когда нужно на 4-м андроиде показывать бесконечную ленту
Я не понял, каким боком тут вообще андроид (вроде же веб-фронт обсуждаем). Но для веб-фронта я бесконечную ленту на бэке делал - ничего сложного, микрокод на JS который дозапрашивает ещё кусок страницы когда скроллер приближается к концу и дописывает присланный бэком кусок html в нужный div.
На бэке от микросервисов лучше всё-таки становится, и значительно. Но для этого нужен хороший архитект, это обязательное условние. (Без него станет хуже, и тоже значительно.) После чего основная сложность остаётся там, где остаются нужны распределённые транзакции/саги в том или ином виде. На фронте транзакций вроде бы нет. Что тогда создаёт сложности в микрофронтендах?
Никакой трансформации никогда не было - законы всегда проводят интересы оного "сильного". Просто в исторические периоды, когда под "сильным" шатается кресло, и ему нужна поддержка голосов/винтовок большинства населения, законы это учитывают. А в периоды, когда "сильному" нужно поднимать экономику, для чего нужно чтобы большинство населения чувствовало себя защищёнными, законы тоже это учитывают. Для упомянутого "большинства" в такие периоды выглядит так, будто с ними считаются и их интересы учитывают - но это только так выглядит.
Там проблема не столько в WASM, сколько в удобной коммуникации между DOM/JS и "нормальным языком" во-первых, и во-вторых в том, что совершенно непонятно что делать с громадным количеством библиотек/компонент на JS, которые необходимы для формирования привычного UI - как правило попытка их использовать совместно с WASM приводит к конфликтам (оба пытаются контролировать одну и ту же часть DOM не зная друг о друге). Очевидное решение этого конфликта - переписать всё на "нормальном языке"… Но пока что-то никто не взялся столько всего переписать.
Это, конечно, правда, но, на мой взгляд, не очень релевантная. Во-первых потому, что на бэке тьма языков но в данном вопросе принципиальной разницы между ними нет. Во-вторых потому, что вроде уже есть консенсунс по использованию TS вместо JS, его поддерживают все основные библиотеки/фреймворки и большинство новых проектов делают на TS.
Никаких противоречий нет - желающие творить фигню найдут способ. Разница в том, что является нормой. Особенности ноды для бэка - не норма, а исключение. Причём так сложилось как раз потому, что нормально ноду воспринимают в основном уже привыкшие к этому беспределу фронтендеры, которым понадобилось немного писать и бэк тоже - а для всех остальных такое на бэке скорее не норма, и они предпочитают более удобные ЯП и инструменты.
Языков без полноценного ООП на бэке полно - тот же Go. Это ничему не мешает, скорее наоборот.
Интерактивности на бэке вообще-то на порядок больше. Это на фронте юзер один, у него одна клава и одна мышка. А на бэке могут быть миллионы одновременно происходящих событий в одном многопоточном сервисе - включая как события от множества юзеров на фронте так и внутренние события бэка. И всё это льётся в общий стейт/БД, взаимодействует друг с другом, и должно обеспечивать консистентность.
Конечно. На бэке полно проблем. Именно поэтому и сформировались довольно жёсткие ограничения, которые мы стараемся соблюдать - где-то это помогает, где-то не до конца. Самое сложное сейчас - правильно определять границы между модулями/микросервисами и корректировать их при изменении бизнес-требований. Тем не менее, по сравнению с происходящим на фронте - на бэке тишина и спокойная работа, с использованием достаточно стабильного набора инструментов.
Любой подвиг - обычно следствие чьей-то ошибки. Если всё делать нормально, то подвиги не понадобятся. Но - всё нормально не делается почти никогда, так что место подвигу всё ещё есть.
Да, почти всё проблемы известные и относительно детские. Но не тогда, когда во-первых ты заранее не знаешь, какие из известных и детских проблем критично проявятся на конкретно этом проекте, и во-вторых когда они на тебя вываливаются внезапно и по нескольку одновременно, и времени на нормальное решение нет, потому что нужно тушить пожары и срочно масштабироваться на порядок. Да, если знать заранее что понадобится то многих проблем можно было бы избежать. Но этого не знает никто. Так что если Cursor с этим справился, значит они молодцы.
Посмотрел прохождения на ютубе. На плейтест не подписывался - лучше не буду портить впечатление багами, дождусь релиза (там, скорее всего, багов на меня ещё оставят ☺).
Of Ash and Steel реально как готика! Теперь придётся ждать, пока выйдет…
Есть мнение, что в момент, когда на коллекцию навешивается бизнес-требование (уникальные заголовки, например), она перестаёт быть "generic" и вполне может быть представлена как агрегат. Потому что если нет, то где тогда описывать данное бизнес-правило?
А ещё данные в БД могут за это время измениться. Потому что сервер параллельно обрабатывает много запросов и таких серверов одновременно работает больше одного. А блокировать нельзя, потому что встанет колом вообще вся система.
Сама концепция наличия в памяти полной модели данных (даже если часть этих данных на самом деле не в памяти а будет магически подгружена ORM при обращении) для обеспечения консистентности этих данных была актуальна в то время и для тех технологий, когда появился DDD - а это более 20 лет назад! Этот поезд давно ушёл. Для современных проектов это совершенно нетипичная и малореалистичная картина.
Микросервис, отвечающий за уникальность заголовков - это же считается норм решение, не нарушающее всякие изоляции, верно? Ну вот и воспринимайте PostgreSQL не тупым хранилищем а таким микросервисом, который следит за уникальностью заголовков, вместо того, чтобы страдать из-за "ой, у нас бизнес-правило из кода домена протекло в схему БД". Просто проверка в бизнес-логике данного правила выполняется не поиском по списку всех заголовков в памяти а попыткой сохранить сущность в БД.
Но… это будет уже не DDD, верно? Потому что DDD ставит задачу написать бизнес-логику так, чтобы её мог прочитать и проверить не программист, а бизнес-заказчик. И тут кусок бизнес-логики оказавшийся очень далеко от изучаемого бизнес-заказчиком кода - аж в схеме БД, - никак не вписывается. Но как часто бизнес-заказчики (не являющиеся программистами) реально читают код бизнес-логики написанный идеально по DDD? Я вот о таком в реальных проектах не слышал в принципе, а Вы? А программист, честно, уж как-нибудь переживёт тот факт, что некоторые элементы бизнес-логики ему нужно смотреть не в этом файле с кодом а в соседнем файле со схемой БД. Программист нуждается в DDD чтобы реально сложную бизнес-логику было возможно загрузить в голову, понять, и корректно изменить - и для этого 100% идеальное следование всем требованиям тактики DDD не требуется, особенно когда из-за попытки делать идеальный DDD общая сложность только вырастает, производительность падает, и появляются новые вызовы - вроде необходимости корректно реализовывать и поддерживать логику компенсации саг.
Удивительное дело, всегда когда агитируют за использование тактики DDD почему-то в статьях и примерах кода забывают упомянуть вопросы работы с транзакциями, выбора границ агрегатов и подходы к обеспечиванию консистентности между разными сервисами и даже разными агрегатами в рамках одного сервиса. А это очень важный (на мой взгляд даже ключевой) момент в тактической части DDD: Пиррова победа Domain-Driven Design.
С этим помогает отказ от религиозного следования догмам. Тактическое DDD - это очень дорогое удовольствие, и нет никакого смысла платить эту цену в 95% сервисов где просто нет настолько сложной бизнес-логики. Никакое "единообразие архитектуры проекта" не стоит этой цены! Поэтому стоит использовать в абсолютном большинстве сервисов Transaction Script (разумеется, плюс гексагональную), и прибегать к тактическому DDD только в тех сервисах, где сложность бизнес-логики действительно на порядок выше средней.
Могу предположить, что бы ответил автор поста: "человек на собственном проде 4 года зависимости не обновляет! Кошмар, что же он будет вытворять на проде компании!!!" ;-)
Вы уже реально задолбали ломать сетевую связность инета! Всё что пингуется - это корректно настроенные компы, в отличие от.
Плюсы - это ещё мелочи. Гораздо хуже то, что многие сайты вообще разрешают регистрировать почту только на доменах крупных провайдеров вроде gmail/yandex. Объясняют они это тем, что мол этот крупняк уже верифицировал юзера, собрал телефоны/капчи, а, значит, можно быть уверенным в том, что это не бот а реальный живой человек (да, author.today, я смотрю в т.ч. на тебя!). Очевидно, что они этим по сути убивают федеративность почты. А вы тут про плюсы плачете…
А смысл? Можно подумать есть примеры, когда суды позволяли решить подобные проблемы (конкретно в РФ и конкретно в последние лет 10). Тут на хабре иногда мелькают статьи пары энтузиастов, которые пытаются что-то в этом направлении делать - но прогресса у них я что-то не припомню. Т.е. писать бумажки можно, и деньги на юриста тратить тоже можно, а вот что-то получить взамен кроме формальных отписок и диких (с точки зрения здравого смысла) решений судов - нет.
А по-моему передёргиваете понятия как раз Вы. Потому что когда домашний пользователь, не ИТшник, начинает настраивать на домашнем роутере VPN, обычно по инструкции которую он толком не понимает, то делает он это исключительно для восстановления доступа к информации, которой привык пользоваться.
Иными словами, технически может Вы и правы, но практически это не имеет значения - все домашние VPN делаются как раз для обхода блокировок, поэтому все попадут под новый закон.
Это правда, но с этим ничего не поделаешь. Суть микросервисной архитектуры в том, что часть сложности переносится из кода в связи между микросервисами. Это позволяет снизить требования к квалификации разработчиков (которых много) за счёт повышения требований к квалификации архитектов (которых мало). Обычно такой размен бизнесу выгоден. Но только при наличии архитекта, который сможет справиться с повысившейся сложностью лично его работы.
А когда этот же UI элемент генерирует бэк что, источников данных становится меньше? Чтобы бэк мог ответить и забыть на нём много всего сделано, чтобы данные из этих разных источников попали в нужном виде в ту БД, из которой бэк "просто ответит и забудет". Всё это - вопрос архитектуры, не больше и не меньше. А когда на архитектуру забили, то и получается "всё переплетено". Это не специфика фронта, это специфика разработки без архитектуры, на бэке так тоже умеют делать.
Не-а. Не "есть". Мы на бэке её себе искусственно организуем (через контейнеры докер). И делаем это как раз потому, что иначе будет куча лишних сложностей. Это как раз один из тех подходов, о которых я говорил, вместе с фиксированным набором разных типов БД и т.п.
Я не понял, каким боком тут вообще андроид (вроде же веб-фронт обсуждаем). Но для веб-фронта я бесконечную ленту на бэке делал - ничего сложного, микрокод на JS который дозапрашивает ещё кусок страницы когда скроллер приближается к концу и дописывает присланный бэком кусок html в нужный div.
А, кстати, почему так?
На бэке от микросервисов лучше всё-таки становится, и значительно. Но для этого нужен хороший архитект, это обязательное условние. (Без него станет хуже, и тоже значительно.) После чего основная сложность остаётся там, где остаются нужны распределённые транзакции/саги в том или ином виде. На фронте транзакций вроде бы нет. Что тогда создаёт сложности в микрофронтендах?
Никакой трансформации никогда не было - законы всегда проводят интересы оного "сильного". Просто в исторические периоды, когда под "сильным" шатается кресло, и ему нужна поддержка голосов/винтовок большинства населения, законы это учитывают. А в периоды, когда "сильному" нужно поднимать экономику, для чего нужно чтобы большинство населения чувствовало себя защищёнными, законы тоже это учитывают. Для упомянутого "большинства" в такие периоды выглядит так, будто с ними считаются и их интересы учитывают - но это только так выглядит.
Там проблема не столько в WASM, сколько в удобной коммуникации между DOM/JS и "нормальным языком" во-первых, и во-вторых в том, что совершенно непонятно что делать с громадным количеством библиотек/компонент на JS, которые необходимы для формирования привычного UI - как правило попытка их использовать совместно с WASM приводит к конфликтам (оба пытаются контролировать одну и ту же часть DOM не зная друг о друге). Очевидное решение этого конфликта - переписать всё на "нормальном языке"… Но пока что-то никто не взялся столько всего переписать.
Это, конечно, правда, но, на мой взгляд, не очень релевантная. Во-первых потому, что на бэке тьма языков но в данном вопросе принципиальной разницы между ними нет. Во-вторых потому, что вроде уже есть консенсунс по использованию TS вместо JS, его поддерживают все основные библиотеки/фреймворки и большинство новых проектов делают на TS.
Никаких противоречий нет - желающие творить фигню найдут способ. Разница в том, что является нормой. Особенности ноды для бэка - не норма, а исключение. Причём так сложилось как раз потому, что нормально ноду воспринимают в основном уже привыкшие к этому беспределу фронтендеры, которым понадобилось немного писать и бэк тоже - а для всех остальных такое на бэке скорее не норма, и они предпочитают более удобные ЯП и инструменты.
Языков без полноценного ООП на бэке полно - тот же Go. Это ничему не мешает, скорее наоборот.
Интерактивности на бэке вообще-то на порядок больше. Это на фронте юзер один, у него одна клава и одна мышка. А на бэке могут быть миллионы одновременно происходящих событий в одном многопоточном сервисе - включая как события от множества юзеров на фронте так и внутренние события бэка. И всё это льётся в общий стейт/БД, взаимодействует друг с другом, и должно обеспечивать консистентность.
Конечно. На бэке полно проблем. Именно поэтому и сформировались довольно жёсткие ограничения, которые мы стараемся соблюдать - где-то это помогает, где-то не до конца. Самое сложное сейчас - правильно определять границы между модулями/микросервисами и корректировать их при изменении бизнес-требований. Тем не менее, по сравнению с происходящим на фронте - на бэке тишина и спокойная работа, с использованием достаточно стабильного набора инструментов.
Любой подвиг - обычно следствие чьей-то ошибки. Если всё делать нормально, то подвиги не понадобятся. Но - всё нормально не делается почти никогда, так что место подвигу всё ещё есть.
Да, почти всё проблемы известные и относительно детские. Но не тогда, когда во-первых ты заранее не знаешь, какие из известных и детских проблем критично проявятся на конкретно этом проекте, и во-вторых когда они на тебя вываливаются внезапно и по нескольку одновременно, и времени на нормальное решение нет, потому что нужно тушить пожары и срочно масштабироваться на порядок. Да, если знать заранее что понадобится то многих проблем можно было бы избежать. Но этого не знает никто. Так что если Cursor с этим справился, значит они молодцы.