В статье Мартина Фаулера и Джеймса Льюиса, в которой описываются достоинства «Microservice Architecture», написано:
Enterprise приложение — приложение, построенное как единое целое. ЛЮБОЕ изменение в системе приводит к пересборке и равертыванию новой версии серверной части приложения.
Понятно стремление авторов быть пропагандистами «Microservice Architecture», однако использование таких определений как ЛЮБОЕ, ВСЕГДА, НИКОГДА говорит о слишком эмоциональном отношении к предмету. Налицо попытка увлечь читателя эмоциями, отключить его мозг. Когда авторы используют такие преувеличения, где-то тут должен скрываться чорт. Так где же он, рогатый?
На мой взгляд, приложение, в котором любое изменение приводит к пересборке — это плохое приложение. Очень плохое. В хорошем приложении ДАЛЕКО не каждое изменение приводит к пересборке. Я знаю много приложений (и сам постоянно делаю такие), в которых появление новой функциональности не приводит к пересборке приложения. Для этого приложение должно уметь интерпретировать метаданные (например, настройки), обмениваться стандартизированными сообщениями и выполнять полезную работу. Компьютер — это устройство интерпретации, хорошее приложение должно быть сделано в той же парадигме.
Предпосылки к созданию приложений, работающих от метаданных, есть. Каждая область деятельности имеет ограниченный круг рутинных операций, форм ввода и отображения данных. Для ввода и отображения данных UI вполне может быть формально описан и интерпретирован приложением. Не только формы ввода информации, но и меню, вопросники, фильтры, отчеты и др. могут быть описаны и интепретированы. Это не значит, что «Microservice Architecture» не
нужна. Это значит, что приложения надо строить, используя разнообразные подходы, избегать культивирования монокультуры, не палить из пушки по воробьям, т.е. включить мозг и не строить плохие приложения на базе «Microservice Architecture». Надо стараться избегать сдвига мотива на цель, чтобы «Microservice Architecture» была для приложений, а не приложения для «Microservice Architecture».
Понятно дело, мода сносит голову, пропагандисты воздействуют на подсознание, создают псевдопонятия. Но, как поется в песне:
Ты запиши к себе в тетрадь
На каждую страницу.
Не надо голову терять,
Не стоит торопиться.
Не надо голову терять,
а вдруг да пригодится.
Enterprise приложение — приложение, построенное как единое целое. ЛЮБОЕ изменение в системе приводит к пересборке и равертыванию новой версии серверной части приложения.
Понятно стремление авторов быть пропагандистами «Microservice Architecture», однако использование таких определений как ЛЮБОЕ, ВСЕГДА, НИКОГДА говорит о слишком эмоциональном отношении к предмету. Налицо попытка увлечь читателя эмоциями, отключить его мозг. Когда авторы используют такие преувеличения, где-то тут должен скрываться чорт. Так где же он, рогатый?
На мой взгляд, приложение, в котором любое изменение приводит к пересборке — это плохое приложение. Очень плохое. В хорошем приложении ДАЛЕКО не каждое изменение приводит к пересборке. Я знаю много приложений (и сам постоянно делаю такие), в которых появление новой функциональности не приводит к пересборке приложения. Для этого приложение должно уметь интерпретировать метаданные (например, настройки), обмениваться стандартизированными сообщениями и выполнять полезную работу. Компьютер — это устройство интерпретации, хорошее приложение должно быть сделано в той же парадигме.
Предпосылки к созданию приложений, работающих от метаданных, есть. Каждая область деятельности имеет ограниченный круг рутинных операций, форм ввода и отображения данных. Для ввода и отображения данных UI вполне может быть формально описан и интерпретирован приложением. Не только формы ввода информации, но и меню, вопросники, фильтры, отчеты и др. могут быть описаны и интепретированы. Это не значит, что «Microservice Architecture» не
нужна. Это значит, что приложения надо строить, используя разнообразные подходы, избегать культивирования монокультуры, не палить из пушки по воробьям, т.е. включить мозг и не строить плохие приложения на базе «Microservice Architecture». Надо стараться избегать сдвига мотива на цель, чтобы «Microservice Architecture» была для приложений, а не приложения для «Microservice Architecture».
Понятно дело, мода сносит голову, пропагандисты воздействуют на подсознание, создают псевдопонятия. Но, как поется в песне:
Ты запиши к себе в тетрадь
На каждую страницу.
Не надо голову терять,
Не стоит торопиться.
Не надо голову терять,
а вдруг да пригодится.