Неоднозначность MVC

Не нашел блога «веб-программирование», разместил тут. Укажите, пожалуйста, другой блог, если не прав.

Все знают про паттерн MVC.

Постоянно спрашиваю на собеседовании, определение дают похожее. А вот с пониманием проблема — из-за неоднозначности определения (слишком общее). У каждого понимание разное.

Пример. Есть метеостанция. На ней имеется:
— датчики температуры, скорости ветра и давления, преобразующие физические сигналы в электрический (пусть для простоты аналоговый);
— компьютерная модель, делающая предсказания. в нее поступают входные электрические сигналы с датчиков;
— и есть мониторы, которые умеют в разных красивых графиках все выводить.

Задача: разбейте по M,V,C.

В моем понимании:
— датчики это стопроцентно контроллеры. они принимают входные данные, преобразуют к одному виду и передают в модель;
— модель — она и есть модель;
— а мониторы (плюс построители графиков) — это, конечно, представление.

НО!

Нередкие следующие случаи
— датчики люди тоже засовывают в модель. либо интуитивно, либо утверждая, что логика проверки данных и преобразования в один формат это тоже к модели относится.
— отрисовыватели графиков также засовывают в модель. хотя это renderers чистой воды, представление;

и так далее.

Это я к чему? Не стоит полагаться на MVC как на супер-основу, особенно если вы только начали программировать и пришли сразу в web (я до web несколько лет был прикладным программистом, и там бизнес-логика, UI и т.д. хочешь или нет, а приходится разделять).

Почитайте дополнительно книги по проектированию с использованием предметной области. К примеру, «Быстрая разработка ПО» ^[1] Роберта Мартина, или Domain Driven Design ^[2].

Там более узкие, более четкие определения, что к чему относится. Что исключить неоднозначность в разработке и позволит более грамотно проектировать архитектуру ваших приложений.

В комментариях прошу Вас разместить линки на хорошие книги по проектированию архитектуры приложений.

Автор: Cord