The database is not the model but the db operations are usually in the model, right? My point though is in essentially shimming functionality. In my example,

The database is not the model but the db operations are usually in the model, right? My point though is in essentially shimming functionality. In my example, for example, here is how it would work. 1) User requests "save this invoice", which activates a controller script which automates the model elements for "invoice" instantiates an invoice (since this is a stateless web app) and saves it. 2) The model saves the invoice by writing it to the db. 3) Saving to the db fires a trigger which checks ROP vs on-hand and where ROP is greater saves a record in a queue table and issues an asynchronous notification, which doesn't have any immediate effect. 4) Controller commits the db transaction. The DB sends out the notification and makes the rows in the queue table visible. 5) Controller for application b wakes up (let's say every 15 min) and polls for notifications. Ok, we got one. Look up the queue table, prepare the email (model stuff) runt he template (view stuff) and sent it out (model stuff again). So what I am getting at here is a way to have model events have side effects which are outside the scope of Application A, but are at least triggered by model operations. This is not an anti-pattern really because application A is not relying on those side-effects for operation. However if you look at application A as the primary one and application B as contained within it, then application B can only be described as contained within the model of application A, from application A's perspective, because all of its functionality is abstracted behind the model. From application B's perspective, there is a model, a view, and a controller, and it doesn't care as to where notifications and queue table data is coming from. From it's perspective it is a loosely coupled app in its own right. But as always what I am suggesting is that common sense usually determines the best place for a given piece of logic. LedgerSMB is very model-centric but there are cases where we have a fair bit of logic in the controller.* I think that anything which is inherent in the model belongs in the model. So back to the vehicle analogy, a bike object should support a $bike->turn('l') and a $bike->turn('r'). However telling the bike when to turn left is the controller's job. * for example in contact and employee management, the controller has to coordinate a lot of different model operations, leading to unusually long/complex model code in the system.