I highly recommend the Domain Driven Design approach. But I've found it a lot harder to comprehend and make others give it a try (probably orders of magnitude

I highly recommend the Domain Driven Design approach. But I've found it a lot harder to comprehend and make others give it a try (probably orders of magnitude harder than object oriented design or design patterns or normal refactorings). I like to think about designing classes and aranging them in packets/modules/applications more like creating birocratic systems. You have to think in general terms what an institution/building does, what is its core activity, what it is authoritative over, then you design each room/department with its own mini-authority, make sure there is no duplication of authority/data between rooms, make sure each person inside a room does/knows about only the stuff in that room so they can really perform by being specialized and not commuting between rooms with their arms full of customer/citizen's files. Make sure, as much as possible that each room knows about adjacent rooms only (or maybe at least at the same floor). At the same time you have to think how the regular citizens use these institutions and what interfaces you provide them with to solve their requests. You don't want a taxpayer modifying his own tax file, you probably want a clerk to do that; you also don't want a taxpayer visiting 100 rooms to submit his tax files. Then you have to think about how many customers you would serve, how wide the coridors should be made, what kind of security you need at the entrance and so on.