Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Architecture, Design & Strategy

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

Authors

Search

XML Feeds

Google Ads

Tags: data access

comments
Rate Post:
submit to reddit Digg!FacebookDotnetkicks

I was listening to show number 426 on dotnetrocks: Rob Boucher on Application Architecture Guidance! They mentioned the Patterns And Practices Application Architecture Guide 2.0, this guide is available for free on codeplex.

Although it is a Microsoft technology centric guide, there should be chapters for every developer in your group.
Here is one example from the book


Key Design Principles

When getting started with your design, bear in mind the key principles that will help you to create architecture that meets “best practices,” minimizes costs and maintenance requirements, and promotes usability and extendibility. The key principles are:

  • Separation of concerns. Break your application into distinct features that overlap in functionality as little as possible.
  • Single Responsibility Principle. Each component or a module should be responsible for only a specific feature or functionality.
  • Principle of least knowledge.** A component or an object should not know about internal details of other components or objects. Also known as the Law of Demeter** (LoD).
  • Don’t Repeat Yourself (DRY). There should be only one component providing a specific functionality; the functionality should not be duplicated in any other component.
  • Avoid doing a big design upfront. If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. This design principle is often abbreviated as BDUF.
  • Prefer composition over inheritance. Wherever possible, use composition over inheritance when reusing functionality because inheritance increases the dependency between parent and child classes, thereby limiting the reuse of child classes.

The nice thing is that each chapter has a resource section at the bottom so that you can dive deep into a specific topic mentioned in the chapter itself. This is great stuff and I recommend that you check out this guide. You also might want to listen to the dotnetrocks podcast about this guide: http://www.dotnetrocks.com/default.aspx?showNum=426




Here is a list of all the chapters, make sure you check out the cheat sheets


Chapters


Part I, Fundamentals


Part II, Design


Part III, Layers


Part IV, Archetypes


Appendix


Errata Page

About the Author

User bio imageDenis has been working with SQL Server since version 6.5. Although he worked as an ASP/JSP/ColdFusion developer before the dot com bust, he has been working exclusively as a database developer/architect since 2002. In addition to English, Denis is also fluent in Croatian and Dutch, but he can curse in many other languages and dialects (just ask the SQL optimizer) He lives in Princeton, NJ with his wife and three kids.
Social SitingsTwitterFacebookLinkedInHomePageLTD RSS Feed
1570 views
submit to reddit Digg!FacebookDotnetkicks

Comments and Feedback