tgoop.com/emacsway_log/1382
Last Update:
Начнем с Solution Space, или почему вносить изменения в проект становится дорого.
В начале 2000-х размер средней системы на рынке постоянно возрастал и достиг такого предела, когда создавать системы по-старому было уже затруднительно. Основных сдерживающих фактора было два:
1) Когнитивная нагрузка на команду. Размер единовременно рассматриваемой сложности превосходил возможности краткосрочной памяти человека (Закон Миллера). Причем, это была именно существенная сложность, которая не решалась появлением очередного фреймворка. Требовался пересмотр основ моделирования.
2) Проблема Брукса. Рост коммуникативной нагрузки между командами.
По этим же причинам и сегодня многие современные рыночные проекты достигают кризиса по мере увеличения своего размера и численности коллектива разработки. Они просто достигают такого предела, когда развиваться по-старому они больше не могут. И никакой очередной фреймворк, никакая "серебрянная пуля" здесь помочь уже не могут.
Эволюционно эта проблема была решена появлением концепции Bounded Context, на основе которой сформировалась микросервисная архитектура. Ключевое отличие микросервисной архитектуры от сервис-ориентированной заключается в том, что первая отдает предпочтение автономности в ущерб реиспользованию, в то время как вторая - наоборот. Подробней этот вопрос рассматривается в "Microservices Architecture" by The Open Group и в "TOGAF® Series Guide Microservices Architecture (MSA) Prepared by The Open Group MSA Work Group".
Остановимся подробней на том, каким образом концепция Bounded Context может способствовать удешевлению разработки.
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1382