I’m a big advocate of setting out the key elements of the development process succinctly but unambiguously at the start of a software development project, particularly in cases where I have no prior history of working with the development team. Such process elements typically cover environments, coding standards, technical design and review requirements, source-code control strategy etc. Perhaps the most valuable area to cover are the basic patterns of construction (or Design Patterns), without this developers are left to their own devices in naming technical components and structuring code, which can be a serious issue with maintainability and standardisation. It is incredibly time expensive and de-motivating to address this after the fact. Instead a clear picture provided upfront can provide the development team with a strong reference covering 80% of the cases, the remainder can be addressed individually during technical design. The example below provides an example of a basic construction pattern which covers naming conventions and structural concerns. Following such a pattern makes the technical implementation predictable and should improve maintainability, the latter being a obligation to take seriously on consulting projects. My rule of thumb is to try and leave the org in a state a future me would consider acceptable.
Audit9 - Cloud Architects 
A great summary representation, I’ll be reusing some of the annotation approaches you’ve used here, great blog! You may be interested in a series of articles i’ve been running on Apex Enterprise Patterns. http://andyinthecloud.com/2013/04/24/apex-enterprise-patterns-domain-layer/
Great blog post and I couldn’t agree more.
@andyinthecloud I’ve read your Apex Enterprise Patterns article and would love to see a similar diagram around your apex enterprise patterns series. I’m having trouble comparing the two design guides. For example, where does your SObjectDomain/SObjectUnitOfWork class belong? Does that take place of the Manager class. Also, in your example you recommend naming a class in the plural form, i.e. “Opportunities”. Does that take place of the Wrapper class in this force365 diagram? Thanks.
Do you have any sample code using these patterns that you could post or throw up on GitHub? Specifically looking for an example of how the Controller, Wrapper, Manager and Validator all work together in actual implementation. I’m very interested to see how you implement the Manager to handle all select, insert, upsert logic. Thank you and again great article!