В вашем подходе (CRUD) действительно зависят. Но в DDD слои слабо зависят друго от друга и вы можете независимо от других слоёв вести разработку API. Кроме того есть совместимость которая запрещает ломать старый API.
В нормально построенных микросервисах (Event Sourcing) взаимодействие происходт асинхронно, и тормозящий сервис просто будет компенсирован Eventual Consistency.
Ещё раз. Язык не содержит CRUD методов. То есть конечно он может содержать метод Create, если у бизнеса есть такой термин. Но бизнес не говорит на языке CRUD (вместо "создай вакцину в шприце", "обнови кровь у пациента" бизнес испольует "поставь вакцину" - это фрагмент из книги, которую вы читали).
И даже в вашем примере ошибка - пара глаголов Create как бы намекают на разнесение в разные Bounded Context.
По CRUD и DDD - вы Эванса то вообще читали (это не оскорбление, это удивление)? Методы и названия переменных берутся из существительных и глаголов универсального языка. Универсальный язык не состоит из 4 глаголов (создать, изменить, удалить, прочитать) это язык описания бизнес логики. Это главная суть DDD так-то - уход от CRUD.
Microservices and Domain-driven design are two different things but it comes hand to hand while implementing the microservices.
Это просто рандомная ссылка, но они блин все такие) Микросервисы позволяют масштабироваться горизонтально. А я посмотрю как вы будете монолит горизонтально масштабировать.
Microservice is a small, loosely coupled service that is designed to perform a specific business function and each microservice can be developed, deployed, and scaled independently.
Видите в определении микросервисы business function? Это DDD.
DDD, event sourcing, cqrs собираются как пазл когда нужно масштабироваться и внедрить микросервисы. В книгах типа Вернона(а также Уди Дахана, Криса Ричардсона и т.д.) описано как всё это работает в комплексе и почему так.
Луковая архитектура не помогает уйти от бд, я писал что Роберт Мартин упомянул об этом в книге Чистая архитектура, как прогноз на дальнейшее развитие.
DDD и CRUD. DDD уже переводится как предметно-ориентированное программирование. CRUD это 4 операции, где здесь предметная область? Вы откуда это взяли, дайте сылку? Я ещё раз только что гуглил - нет либо DDD либо CRUD.
Естественно чистый DDD ничего про бд не говорит, как и про реализацию кстати. Но надо понимать что DDD нашёл своё применение в микросервисной архитектуре наряду с другими хорошими практиками как cqrs, event sourcing и т.д. Вот о таком расширенном понимании DDD я и пишу, возможно не совсем корректно. Про уход от бд было у Роберта Мартина, чья луковая архитектура идеально ложится под реализацию DDD.
В целом с вами согласен, кроме crud. Везде пишут что в случае crud DDD избыточен, есть даже обсуждение на stackoverflow ссылку приводить не буду, легко гуглится.
Это не просто избегание джойнов, а целая философия (DDD). Если вкратце, то есть у разработчиков мечта отказаться от бд(и вместе с ней sql, джойнов и прочей сложности) и хранить объекты в оперативке так же, как они заданы в коде. Но поскольку прогресс ещё не дошел до супер дешёвой оперативки, появилась технология nosql.
Эта философия накладывает сильные ограничения на архитектуру приложения. Например, вместо ограничений бд, за консистентностью следит рутовый объект(агрегат) документа монго. При этом агрегат составлен так, чтобы быть понятным бизнесу(аналитикам, менеджерам, клиентам) это фишка DDD.
DDD используется в основном для сложной бизнес логики, то есть если у вас CRUD, то DDD избыточен и как следствие в монго нет смысла, используйте реляционку. Если вы пошли по пути DDD то в вашей ответственности задать агрегаты вмещающимся в 16mb. А если агрегат хранит нечто не вписывающееся в бизнес логику, то лучше вынести это в S3.
Конечно, в Кафке есть транзакции и можно реализовать транзакции самостоятельно в коде. Но не юродствуйте, ваш посыл был не об этом. Напоминаю, вы писали что когда транзакция выполняется на стороне бд, консистентность проверяется также приложением, а не только бд.
Не буду давать вам ценных советов и отсылать к авторитетам. Вот так кратко и всем понятно можно излагать свои мысли, для этого не надо ссылаться на две главы учебника.
Не совсем. Я утверждаю, что согласованность на уровне бд обеспечивается транзакциями. В то время как согласованность бл обеспечивается механизмами приложения, например как в случае eventual consistency.
Автор утверждает что и бл и бд это свойство транзакции (C из ACID).
Транзакции это прерогатива базы данных. У бд есть командная строка и она о целостности данных в приложении ничего не знает. Как вы реализовываете транзакции? Они уже реализованы в бд, вы их только используете.
Так можно далеко зайти в переложении ответственности и вообще непонятно будет где код, а где инфраструктура.
Я согласен, что для узких ниш, таких как игры или какие-нибудь Яндекс навигаторы алгоритмы нужны. Но не для enterprise разработки, в которой задействовано подавляющее большинство. Я работаю в энтерпрайз достаточно давно и не приходилось мне ни разу использовать алгоритмы, поэтому заявления о повседневном их использовании видятся мне как желание возвысить ремесло разработки над остальными, показать свою эксклюзивность.
В вашем подходе (CRUD) действительно зависят. Но в DDD слои слабо зависят друго от друга и вы можете независимо от других слоёв вести разработку API. Кроме того есть совместимость которая запрещает ломать старый API.
В нормально построенных микросервисах (Event Sourcing) взаимодействие происходт асинхронно, и тормозящий сервис просто будет компенсирован Eventual Consistency.
Ещё раз. Язык не содержит CRUD методов. То есть конечно он может содержать метод Create, если у бизнеса есть такой термин. Но бизнес не говорит на языке CRUD (вместо "создай вакцину в шприце", "обнови кровь у пациента" бизнес испольует "поставь вакцину" - это фрагмент из книги, которую вы читали).
И даже в вашем примере ошибка - пара глаголов Create как бы намекают на разнесение в разные Bounded Context.
Только понимание прочитанных вами книжек и докладов противоречат и самим книгам и докладам и мнению сообщества.
-- Да и выделение сервисов по бизнес-функциям - довольно спорная идея
-- И да, про " developed, deployed, and scaled independently" - это рекламная агитка
-- Business function - это не DDD, это просто про "бизнес-функции"
По CRUD и DDD - вы Эванса то вообще читали (это не оскорбление, это удивление)? Методы и названия переменных берутся из существительных и глаголов универсального языка. Универсальный язык не состоит из 4 глаголов (создать, изменить, удалить, прочитать) это язык описания бизнес логики. Это главная суть DDD так-то - уход от CRUD.
https://stackoverflow.com/questions/70479400/what-are-the-differents-between-microservices-and-domain-driven-design
Вообще очень похоже на тонкий троллинг.
Scalability is a critical aspect of microservices architecture.
Источник: https://www.atmosly.com/blog/scaling-microservices-for-optimal-performance#:~:text=Scalability%20is%20a%20critical%20aspect,%E2%80%94%20smoothly%2C%20without%20compromising%20performance.
Это просто рандомная ссылка, но они блин все такие) Микросервисы позволяют масштабироваться горизонтально. А я посмотрю как вы будете монолит горизонтально масштабировать.
Microservice is a small, loosely coupled service that is designed to perform a specific business function and each microservice can be developed, deployed, and scaled independently.
Видите в определении микросервисы business function? Это DDD.
DDD и CRUD
https://stackoverflow.com/questions/23970567/ddd-and-avoiding-crud
CRUD for a BC that has very little domain complexity and DDD for an area with high complexity.
Вот цитата, CRUD для простых случаев, DDD для сложных.
Ещё раз прошу приведите ссылку откуда вы всё это взяли? Или это просто ваше мнение?
DDD, event sourcing, cqrs собираются как пазл когда нужно масштабироваться и внедрить микросервисы. В книгах типа Вернона(а также Уди Дахана, Криса Ричардсона и т.д.) описано как всё это работает в комплексе и почему так.
Луковая архитектура не помогает уйти от бд, я писал что Роберт Мартин упомянул об этом в книге Чистая архитектура, как прогноз на дальнейшее развитие.
DDD и CRUD. DDD уже переводится как предметно-ориентированное программирование. CRUD это 4 операции, где здесь предметная область? Вы откуда это взяли, дайте сылку? Я ещё раз только что гуглил - нет либо DDD либо CRUD.
Естественно чистый DDD ничего про бд не говорит, как и про реализацию кстати. Но надо понимать что DDD нашёл своё применение в микросервисной архитектуре наряду с другими хорошими практиками как cqrs, event sourcing и т.д. Вот о таком расширенном понимании DDD я и пишу, возможно не совсем корректно. Про уход от бд было у Роберта Мартина, чья луковая архитектура идеально ложится под реализацию DDD.
В целом с вами согласен, кроме crud. Везде пишут что в случае crud DDD избыточен, есть даже обсуждение на stackoverflow ссылку приводить не буду, легко гуглится.
Да, я опираюсь на Вернона. Что вы находите странного в моём понимании?
Domain driven design.
Это не просто избегание джойнов, а целая философия (DDD). Если вкратце, то есть у разработчиков мечта отказаться от бд(и вместе с ней sql, джойнов и прочей сложности) и хранить объекты в оперативке так же, как они заданы в коде. Но поскольку прогресс ещё не дошел до супер дешёвой оперативки, появилась технология nosql.
Эта философия накладывает сильные ограничения на архитектуру приложения. Например, вместо ограничений бд, за консистентностью следит рутовый объект(агрегат) документа монго. При этом агрегат составлен так, чтобы быть понятным бизнесу(аналитикам, менеджерам, клиентам) это фишка DDD.
DDD используется в основном для сложной бизнес логики, то есть если у вас CRUD, то DDD избыточен и как следствие в монго нет смысла, используйте реляционку. Если вы пошли по пути DDD то в вашей ответственности задать агрегаты вмещающимся в 16mb. А если агрегат хранит нечто не вписывающееся в бизнес логику, то лучше вынести это в S3.
А, то есть приложение не проверяет консистентность транзакции? Следовательно C это свойство бд, а не бд и приложения?
Конечно, в Кафке есть транзакции и можно реализовать транзакции самостоятельно в коде. Но не юродствуйте, ваш посыл был не об этом. Напоминаю, вы писали что когда транзакция выполняется на стороне бд, консистентность проверяется также приложением, а не только бд.
Не буду давать вам ценных советов и отсылать к авторитетам. Вот так кратко и всем понятно можно излагать свои мысли, для этого не надо ссылаться на две главы учебника.
Про вас есть выражение: "всё понимает, а сказать не может".
Не совсем. Я утверждаю, что согласованность на уровне бд обеспечивается транзакциями. В то время как согласованность бл обеспечивается механизмами приложения, например как в случае eventual consistency.
Автор утверждает что и бл и бд это свойство транзакции (C из ACID).
Да, это известная отмазка когда нечего ответить. Кратко формулировать мысли вы умеете?
То есть ответить вы не в состоянии?
Транзакции это прерогатива базы данных. У бд есть командная строка и она о целостности данных в приложении ничего не знает. Как вы реализовываете транзакции? Они уже реализованы в бд, вы их только используете.
Так можно далеко зайти в переложении ответственности и вообще непонятно будет где код, а где инфраструктура.
По такой логике и изоляция свойство приложения. Ведь можно программно сделать транзакции идущими одна за другой?
А почему согласованность это свойство приложения? Разве это не о внешних ключах и констрейнтах бд?
Всё с вами ясно.
Я согласен, что для узких ниш, таких как игры или какие-нибудь Яндекс навигаторы алгоритмы нужны. Но не для enterprise разработки, в которой задействовано подавляющее большинство. Я работаю в энтерпрайз достаточно давно и не приходилось мне ни разу использовать алгоритмы, поэтому заявления о повседневном их использовании видятся мне как желание возвысить ремесло разработки над остальными, показать свою эксклюзивность.
То есть названия применённого алгоритма не будет?