Hi HN!<p>I am wondering what your takes are when it comes to coupling & cohesion and establishing more rigid boundaries in software apps.<p>To me developers seem to have no problem with accepting strict boundaries when dealing with third party (web) interfaces they have no immediate control over, they use parts of the interface they desire, they cherrypick the response content and create a tailored model & logic set.<p>When there's control over the existing models and interfaces, the allure to use them directly and to modify, connect, extend or increase the amount rather than creating boundaries, seems present.<p>I recently worked on a multi purpose solution containing 3 projects: FE, BE and tests.<p>Its database and solution feel like they cover too many things, yet its inception predates when I was born, challenging my understanding.<p>The app at hand depends on 10 apps and has 20 dependants itself.<p>The solution consists out of 500k LOC (200k code, 300k tests).<p>For the domain & logic, there are table:entity models, CQRS handlers with their own model tailored to the SQL query and MVC using those handlers. Handlers can use "services", the meaning varies, sometimes it's deduped logic, a repo, ...<p>By chance, I got to see what the FE UI of the app looked like 20y ago. In terms of conceptual concerns it seemed to be similar (75%) but with less depth.<p>The legacy schema was accompanied by a new schema 10y ago. Its used to wrap legacy tables using views but also provides insight into which tables were introduced post schema introduction. Revealing an expansion of 30% since then, confirming my estimate comparing the FE UI's. How much the tables themselves have changed, I'm not able to determine.<p>Judging from the entities, each appears to have a large amount of relationships with other entities. E.g. instead of (A > B > C) it's (A > B, B > C, A > C) or similar. I did not manage to generate diagrams due to SSMS & DG crashing due to the sheer size of the db, so I can not judge the entirety. Could try generating entities UML.<p>With that in mind, and it being the largest project I've ever seen, I wonder if it covers too many things. And if not, at what point would it?<p>The conceptual concerns don't seem to have expanded too much, but it still grew. The fact that the roots of this predate my birth, and enabled the business to operate in n countries is an amazing marvel brought forward by years of dedication.<p>Yet I have to wonder how and why. Main reason seems to me to be its age, considering reqs, practices and tech have evolved since inception. A natural cause, but perpetually modified and expanded upon.<p>A great amount of resistance by its dependencies, size, it not posing a problem (?), and its history. Makes it seem like a big and risky idealistic undertaking, the alternative being stuck with vague boundaries in perpetuity.<p>Most of the CQRS handlers have tailored models, which seems to be a step in the right direction in terms of boundary formation and having the behavior where it belongs.<p>On the other hand, the handlers are not arranged by domain, concern, .. or otherwise. They reside in "feature" folders which mimic the folder structure of the FE practically 1:1.<p>I'm not convinced by that structure, the handlers can be found from the controllers and vice-versa. If folders are mimicked then you might as well put it together instead of pretending the BE has its own structural house rules (infra etc aside, just want to get the point across).<p>Thanks for taking the time to read up until here. I'd really like to hear about your perspectives or experiences!