#предметная_область — Public Fediverse posts

[Перевод] Книга «Изучаем DDD — предметно-ориентированное проектирование». Подробный читательский обзор

Привет, Хабр! На протяжении нескольких лет одной из наиболее популярных и важных книг в нашем арсенале остаётся книга Влада Хононова "

https://habr.com/ru/companies/bhv_publishing/articles/1027422/

#DDD #enterprise #проектирование #предметная_область

[Перевод] Книга «Изучаем DDD — предметно-ориентированное проектирование». Подробный читательский обзор

Привет, Хабр! На протяжении нескольких лет одной из наиболее популярных и важных книг в нашем арсенале остаётся книга Влада Хононова "

https://habr.com/ru/companies/bhv_publishing/articles/1027422/

#DDD #enterprise #проектирование #предметная_область

[Перевод] Книга «Изучаем DDD — предметно-ориентированное проектирование». Подробный читательский обзор

Привет, Хабр! На протяжении нескольких лет одной из наиболее популярных и важных книг в нашем арсенале остаётся книга Влада Хононова "

https://habr.com/ru/companies/bhv_publishing/articles/1027422/

#DDD #enterprise #проектирование #предметная_область

[Перевод] Книга «Изучаем DDD — предметно-ориентированное проектирование». Подробный читательский обзор

Привет, Хабр! На протяжении нескольких лет одной из наиболее популярных и важных книг в нашем арсенале остаётся книга Влада Хононова "

https://habr.com/ru/companies/bhv_publishing/articles/1027422/

#DDD #enterprise #проектирование #предметная_область

Предметно-ориентированное проектирование (DDD) и математическое моделирование

В статье будут проведены аналогии между предметно-ориентированным проектированием и математическим моделированием С математическим моделированием школьники знакомятся в 7 классе общеобразовательной школы. Грубо говоря, это перевод задачи из неформального человеческого языка на язык математики для последующего её решения.

https://habr.com/ru/articles/815497/

#DDD #domaindriven_design #math #математическое_моделирование #предметная_область

DDD простыми словами

Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров. Бывает, что компании решают использовать микросервисный подход, но в результате получают таких же монолитных монстров, но только работающих в Кубере. Границы систем размыты, нет чёткого понимания, что должно входить в систему, а что нет. Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы. По сути, речь идёт о том, что системы становится слишком большими и для их доработки требуется длительный процесс погружения. Можно ли исправить ситуацию коренным образом?

https://habr.com/ru/articles/809831/

#ddd #ограниченный_контекст #bounded_context #ubiquitous_language #domain_driven_design #архитектура #предметная_область