All Your Design Patterns Are Belong To Us

One team I'm on right now is in the process of building a massive application on Laravel. As we've added more design patterns, its obviously gotten more confusing. I'm here to ask you all if it sounds like we're using these design patterns properly and/or for the right purposes, and then for you to recommend the next pattern we incorporate.

We started out simply, using blades, controllers, and Eloquent models. Mostly using the models for defining the fields/attributes, defining relationships, etc.

Soon after, we started using repositories to do more conceptual cross-model queries, such as ->with(). I wouldn't say we're using them as purely "aggregate root" repositories as some people might suggest, but it's in that direction. We're also doing some functional model manipulations there, like fill() and making a record inactive (which then calls the model's store()).

We've also built our first Service Provider and Facade, in order to generalize one of our common UI elements. So we dipped our toe in that pool.

But now that we're getting deeper into the functionality, the business logic, etc, it seems like we have slightly outgrown our set of design patterns again. We're looking at Jobs (commands), we're looking at Service Providers and more Facades, but we're not completely sold on either yet. When do you use which? And why? And/or, are there other design patterns we should be examining to manage business logic? There's got to be a hairy class somewhere that pulls in all the dependencies and uses them. Just need to know where those should be.

Example: When storing an address, depending on the country and postal code, there are hidden fields that need to be filled out. Part of the decisions there include calls to other models/repositories to get reference/configuration data. We could do that: * In the repository, but then you're passing a second repository in as a dependency. Bad. * In a Service Container, but then you're littering static calls via Facades all over. Not great. * In a Job, but then you're abstracting the actual processing so far away from the CRUD operation, you start to lose the plot.

The kicker, of course, is building all this not just in a functional way, but in a SOLID way so we can have actual unit test coverage.