Heh, good job on the homework!
Okay, so a little bit of background. The app is a mostly legacy CodeIgniter PHP application. There's a custom bit of code during the CI application bootstrap that says "if the requested controller/function/JS file/CSS exists in the client's personal directory, use that version instead - if not use the default version". The CI application is mostly unstructured spaghetti code, and generally just not very nice to work with, but this is how the all custom functionality has been implemented up until recently. There has since been a Laravel application added - if the requested route or file exists in the Laravel app, it use that version, otherwise the request is forwarded on to CodeIgniter. This is allowing for a gradual refactor of the app away from CI to Laravel, and this is working nicely.
As far as I'm aware, the company policy has always been to do anything the client wants (long before I started working here) - it has just always been implemented in a less than ideal, almost hacky, way. This has resulted in the spaghetti I refer to above.
Since I started working here, I've been trying to find ways to improve everything, from the way that the application repositories are structured (we've gone from one CodeIgniter repo, plus one default Laravel repo, plus a forked Laravel repo for all ~20 clients, to just a single repo containing everything), to automating what was before a manual, error-prone deployment process.
Regarding the book/ISB example - I had been reading a lot about BDD at the time when I wrote that, and reading about using the correct terminology (the ubiquitous language) that the business uses in the code. I think what I was trying to get across in that example was that when building custom functionality for a client that uses terminology different to everyone else, how to handle that conflict?
You're absolutely right that the core should be more flexible, and that's always at the forefront of my mind. Although the CodeIgniter code base will never be flexible (and we will just have to live with it), we have a real opportunity with the Laravel code base to make it flexible enough for all clients, while adhering to modern practices. We really feel we're in a good position on the Laravel side of things now (using dynamic runtime service container configuration) - the last piece of the puzzle is how to do achieve similar results with the existing JS/SASS using within the Laravel app, and any new JS/SASS that we write, which is proving a difficult problem to solve, hence this post :)