Software architecture diagrams are a fantastic way to communicate how you are planning to build a software system (up-front design) or how an existing software system works (retrospective documentation, knowledge sharing, and learning).
However, it’s very likely that the majority of the software architecture diagrams you’ve seen are a confused mess of boxes and lines.
The Over Designer Have you ever encountered an over designer? An over designer is a software developer that had some life changing event and became obsessed about architecture. The result being, obsessive decoupling, endless coding of Factories, creating deep (also needless) inheritence hierarchies and various use of design patterns for no good reason.
I’ve spoken several times about a specific type of architecture I call “Onion Architecture”. I’ve found that it leads to more maintainable applications since it emphasizes separation of concerns throughout the system. I must set the context for the use of this architecture before proceeding. This architecture is not appropriate for small websites. It is appropriate for long-lived business applications as well as applications with complex behavior. It emphasizes the use of interfaces for behavior contracts, and it forces the externalization of infrastructure.
This one looks like a great .NET lightweight ORM:
PetaPocoA tiny ORM-ish thing for your POCOsPetaPocoMainDocumentationLicensePetaPoco is a tiny, fast, single-file micro-ORM for .NET and Mono.Like Massive it’s a single file that you easily add to any projectUnlike Massive it works with strongly typed POCO’sLike Massive, it now also supports dynamic Expandos too – read moreLike ActiveRecord, it supports a close relationship between object and database tableLike SubSonic, it supports generation of poco classes with T4 templatesLike Dapper, it’s fast because it uses dynamic method generation (MSIL) to assign column values to properties
Source: PetaPoco – Topten Software
The goal of this series is to show you an example how you could design a system. It’s kind of a reference architecture that I like to use (I have used it – a number of times in middle-sized projects, and I’m still quite happy about it), but it’s up to you to decide if you find some ideas to be usable in your specific environment.
Source: A reference architecture (part 1) | Dunatis