E>>Я уверен, что ты и сам понимаешь почему и зачем придуманы архитектуры.
S>Затем, что бы удовлетворять требованиям. Техническим, и не только. И мне представляется нелепым обсуждать то, чем такое расположение слоев лучше чем другое в контексте неопределенных требований.
S>Собственно, я и пытаюсь склонить обсуждение к перечислению факторов, в рамках которых принято что одна архитектура лучше другой и слои должны взаимодействовать именно таким образом.

Ну так бы прямо и сказал: перечисли факторы такие-то и такие-то.
А то как-то не понятно что и к чему.

S>Если считаешь мои наводящие вопросы неконструктивными, то я найду куда пойти и чем заняться.

Я всегда "ЗА" общение, которое помогает решить проблему.
Только, пожалуйста, выражайся яснее.

S>До этого момента было обсуждение вопроса о том, "бывает ли такое". Никаких предложений не требовалось до сообщения, на которое я отвечаю. Я даже и подумать не мог, что мне нужно что-то предложить.

Ну как же...
Вот я прямо в первом сообщении написал (помимо "бывает ли такое"):
"Если ... так делается, то как реализуется такое управление?
Как сделать внешний слой, о котором по сути Бизнес-логика ничего не знает, управляемым?"


S>А теперь мне не хватает данных, что бы что-то предлагать. Даже не считаю что тезиса (1) достаточно для качественных предложений.

Попробую объяснить подробнее.
Есть сложный бизнес-сценарий, который читает из БД данные, преобразует их, записывает в преобразованном виде во внешний файл, сохраняет в БД новые сформированные данные.
В этом сценарии много ответвлений, условий и "развилок", которые зависят от конкретного состояния данных, от результата выполнения действий с БД и файловой системой.
При возникновении этих развилок нужны дополнительные данные, которые надо запросить у пользователя.
И выполнение сценария продолжается в зависимости от ответа пользователя.

Каким образом запросить данные у пользователя так, чтобы не зависеть от слоя UI?
Ведь слой Бизнес-логики не должен зависеть от UI.

Очень упрощенный пример.
Мы в редакторе сохраняем файл, указываем имя.
Бизнес-логика при попытке сохранения файла обнаруживает, что такой файл уже существует.
Дальше она задает вопрос пользователю: "Что дальше делать?". Обычно предлагаются следующие варианты "Заменить, Сохранить под другим именем, Отменить".
Однако, таких вариантов может быть больше и они определяются возможностями бизнес-слоя.
Например, более "продвинутый" бизнес-слой мог бы предложить такие дополнительные варианты действий: "Дописать в существующий файл", "Сохранить под указанным именем переименовав существующий файл" и т. д.

S>>>Я пытаюсь выяснить, чем лучше архитектура, предложенная Мартином? Но конкретно, а не просто "удобнее". Удобнее чем что? Удобнее чем? Для какого типа приложений?

E>>Ну какая разница какая архитектура лучше или хуже?
S>Если разницы нет, бери архитектуру God Project (по аналогии с God Object) и не парься над слоями.

Ты сам прекрасно понимаешь, почему так не следует делать.
Следуя твоему примеру, покажу как выглядит наш диалог с моей точки зрения:
— Я: "Как разделить слои"
— Ты: "Надо делить для конкретной цели"
— Я: "Цель такая-то. Как делить?"
— Ты: "Можешь не делить"
— Я: "Но лучше разделить. Как правильно разделить?"
— Ты: "А зачем делить?"
— Я: "За тем-то и затем-то"
— Ты: "Не обязательно делить"