Где «уровень бизнес-логики» вписывается в приложение MVC?

Прежде, чем кто-нибудь закричит, Мне было трудно выразить это простым заголовком. Другой заголовок мог бы быть «В чем разница между моделью предметной области и моделью MVC?» или «Что такое модель?»

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

Например, в недавнем вопросе, который я задал о шаблоне репозитория, мне прямо сказали, что репозиторий является частью модели. Однако я читал другие мнения о том, что модель должна быть отделена от модели сохранения и уровня бизнес-логики. В конце концов, разве нет • Шаблон репозитория должен отделить конкретный метод сохранения от модели? Другие люди говорят, что есть разница между моделью домена и моделью MVC.

Возьмем простой пример. AccountController, включенный в проект MVC по умолчанию. Я читал несколько мнений о том, что включенный код учетной записи плохо спроектирован, нарушает SRP и т. Д. И т. Д. Если бы кто-то разработал «правильную» модель членства для приложения MVC, что бы это было?

Как Вы бы отделили службы ASP.NET (поставщик членства, поставщик ролей и т. д.) от модели? Или бы вы вообще?

На мой взгляд, модель должна быть «чистой», возможно, с логикой проверки ... но должна быть отделена от бизнес-правил (кроме проверки). Например, пусть ' s Допустим, у вас есть бизнес-правило, согласно которому при создании новой учетной записи необходимо отправить письмо по электронной почте. На мой взгляд, это не относится к модели. Так где же он?

Кто-нибудь хочет пролить свет на эту проблему?