我认为您介绍的所有模式/架构都非常有用，只要您遵循SOLID原则。
对于在哪里添加逻辑，我认为参考单一责任原则很重要。另外，我的答案认为您正在从事中型/大型项目。如果这是一个在页面上抛出的东西项目，忘记这个答案，把它全部添加到控制器或模型中。
简短的回答是：对你有意义的地方（通过服务）。
长答案：
控制者：控制者的责任是什么？当然，您可以将所有逻辑放在控制器中，但这是控制器的责任吗？我不这么认为。
对我来说，控制器必须接收请求并返回数据，这不是放置验证，调用db方法等的地方。
模型：这是否是添加逻辑（如在用户注册时发送欢迎电子邮件或更新帖子的投票计数）的好地方？如果您需要从代码中的其他位置发送相同的电子邮件，该怎么办？是否创建静态方法？如果该电子邮件需要来自其他模型的信息，该怎么办？
我认为模型应该代表一个实体。使用Laravel，我只使用模型类来添加诸如，和关系之类的东西（这是因为我使用存储库模式，否则模型也将具有，，等方法）。fillableguardedtablesaveupdatefind
存储库（存储库模式）：一开始我对此感到非常困惑。而且，像你一样，我想“好吧，我使用MySQL，仅此而已。
但是，我已经平衡了使用存储库模式的优缺点，现在我使用它。我认为现在，此时此刻，我只需要使用MySQL。但是，如果三年后我需要改用MongoDB之类的东西，大部分工作都完成了。所有这些都是以牺牲一个额外的接口和一个.$app->bind(«interface», «repository»)
事件（观察者模式）：事件对于可以在任何给定时间在任何类上抛出的东西很有用。例如，考虑向用户发送通知。需要时，可以触发事件以在应用程序的任意类上发送通知。然后，您可以有一个类似的类来处理用户通知的所有触发事件。UserNotificationEvents
服务：到目前为止，您可以选择向控制器或模型添加逻辑。对我来说，在服务中添加逻辑是有意义的。让我们面对现实吧，服务是类的一个花哨的名字。而且，您可以在您的应用程序中拥有对您有意义的任意数量的类。
举个例子：不久前，我开发了类似Google Forms的东西。我从 a 开始，最后以 、 、 、 和 .为什么？因为它对我来说是有道理的。如果你与一个团队合作，你应该把你的逻辑放在对团队有意义的地方。CustomFormServiceCustomFormServiceCustomFormRenderCustomFieldServiceCustomFieldRenderCustomAnswerServiceCustomAnswerRender
使用服务与控制器/模型的优点是，您不受单个控制器或单个模型的约束。您可以根据需要创建任意数量的服务，具体取决于应用程序的设计和需求。除此之外，还可以在应用程序的任何类中调用服务。
这很长，但我想向您展示我如何构建我的应用程序：
app/
controllers/
MyCompany/
Composers/
Exceptions/
Models/
Observers/
Sanitizers/
ServiceProviders/
Services/
Validators/
views
(...)
我将每个文件夹用于特定功能。例如，该目录包含一个负责处理验证的类，该类基于特定验证程序的 和（通常每个模型一个）。我可以很容易地将此代码放在服务中，但是对我来说，即使仅在服务中使用（目前），为此设置一个特定的文件夹也是有意义的。ValidatorsBaseValidator$rules$messages
我建议您阅读以下文章，因为它们可能会更好地向您解释事情：
Dayle Rees（CodeBright的作者）的《Breaking the Mold》：这就是我把它们放在一起的地方，尽管我为了满足我的需求而改变了一些东西。
Chris Goosey在Laravel中使用Repositories and Services解耦你的代码：这篇文章很好地解释了什么是服务和存储库模式，以及它们如何组合在一起。
Laracasts还有简化的存储库和单一责任，这些都是很好的资源，有实际的例子（即使你必须付钱）。
