@jaw - I have; but first, a rant: Architecture with a big A is something that is often looked down upon in this community, because it has the bad rap of being

@jaw - I have; but first, a rant: Architecture with a big A is something that is often looked down upon in this community, because it has the bad rap of being over-engineered, not scalable, "done by contractors who don't know anything/are trying to pad billable hours", et cetera. I can see this in the kind of schlock being peddled as the next great front-end/web solution; usually done by people who would do very well to revisit the last 30-40 years in thinking about the Design of software. Thinking that testing and TDD are replacements for and/or better than static typing is Pretty Fucking Stupid™. Design Patterns as given by GoF, Fowler, etc are more often than not questionable, but design patterns extracted from your code base are worth their weight in gold. We have a beefy .NET codebase composed of some 80+ projects (used to be more then we trimmed it down) integrating with 25+ external data sources/APIs and we have leveraged every single fucking thing out there to make sense of it and not let it overwhelm our systems. Type-level invariants along with a layered validation system is definitely something that we made a bet early on and it paid off. It's very hard to mess it up once it is in place, and not that difficult to understand. Some of the things we applied are discussed in Enterprise Architecture by Fowler, the Domain Driven Design book also discusses it a bit. Your own application of these principles is what matters, and that's where things get hairy. .NET/C# is nice because it provides enough facilities through Reflection and Attributes to be able to "pattern"-ize some of the things that come up, and there are other languages that do it better still. I really like Ruby's method_missing and I wish that C# provided an equivalent, but to my knowledge most of the approaches within C# to do something like that are kludges at best.