Как описать приготовление яичницы в терминах MVC?

С течением времени было множество трактовок.
Одним из примеров MVC является - игровая приставка.

Model - сама приставка
View - телевизор, который подключается к приставке
Controller - контроллер для игровой приставки (манипулятор), так и называется. Неофициально - "джойстик".

Ключевым моментом является Model (сама приставка), в ней происходят все сложные процессы и вычисления, хранение данных и просчёты.
View, что в соответствии телевизор, - это лишь средство представления информации с вида, удобного для приставки (нули и единицы), в вид, удобный для человека.
Controller, что в соответствии игровой контроллер, - это способ преобразования команд с вида, удобного для человека (вперёд, прыжок), в вид, удобный для приставки.

Модель, в принципе, подразумевает у неё самой наличие функций, позволяющих ей меняться. Контроллер лишь командует - в какой момент времени каким функциям нужно вызваться, чтобы поменять модель. Если убрать из системы игровой контроллер, и попытаться отвёрткой замыкать контакты в гнезде игровой приставки (т. е. обратиться напрямую в модель, минуя контроллер), пытаясь тем самым "управлять персонажем", то это будет затруднительно - куда проще нажать на кнопку, а контроллер преобразует это в нужный вид.

Картинка из вики:

Если упрощенно, приготовление яичницы в кафе

Официант — это Controller
Повар — это Model
Яичница на столе — это View

Посетитель сделал заказ яичницы через официанта (C). Официант передал заказ повару (M). Повар приготовил и официант поставил тарелку на стол (V) посетителю

Конечно, в оригинальном MVC стол как-то сам должен отображать то, что приготовил повар, без участия официанта :)

MVC на примере авто

Бизнес-процесс - приготовление яичницы.

Плохой пример. Приготовление яичницы - это бизнес-процесс, разделенный на множество других процессов. Бизнес-процесс как таковой - это часть модели.

Про бизнес-процессы сказали правильно. Я добавлю что существует два MVC, один для толстых клиентов (фронтенд), другой для клиент-серверной архитектуры, то что в рамках http. Они сильно отличаются и каждая из этих версий опирается на особенности среды, в рамках которой используется: в клиентах событийная модель, в бекенде клиент-серверная.

Но и там и там M - это ваша предметная область, то что не зависит от того где и как используется. Процесс заказа яичницы это бизнес-процесс, будет абсолютно идентичным, с алгоритмической точки зрения, где бы вы его не реализовывали.

Я бы в данном контексте разделил следующим образом:
- Модель — это ингредиенты блюда (яйца, помидоры, соль... и т.д.);
- Контроллер — это весь процесс приготовления (если вы в кафе, то это и официант, и повар, и посудомойщица... и рецепт);
- Представление — это ваша тарелка (которая в начале была пустой, а после того как, вы сделали заказ, и подождали, пока контроллер отработает, «показывает» вашу яичницу).
Да, если вы в кафе, то это бизнес приложение, и контроллер получается толстоват, его можно разбить на составные MVC.
Если же, вы дома себе готовите, то это очевидно более простое приложение, и контроллер попроще.
Как-то так...