Just quoting “key principle design” from dot net application guide 2.0.
Key Design Principles
When getting started with your design, keep in mind the key principles that will
help you to create an architecture that adheres to proven principles, minimizes costs
and maintenance requirements, and promotes usability and extendibility. The key
Separation of concerns. Divide your application into distinct features with as
little overlap in functionality as possible. The important factor is minimization of
interaction points to achieve high cohesion and low coupling. However, separating
functionality at the wrong boundaries can result in high coupling and complexity
between features even though the contained functionality within a feature does not
Single Responsibility principle. Each component or module should be responsible
for only a specific feature or functionality, or aggregation of cohesive functionality.
l Principle of Least Knowledge (also known as the Law of Demeter or LoD). A
component or object should not know about internal details of other components
Don’t repeat yourself (DRY). You should only need to specify intent in one place.
For example, in terms of application design, specific functionality should be implemented
in only one component; the functionality should not be duplicated in any
Minimize upfront design. Only design what is necessary. In some cases, you may
require upfront comprehensive design and testing if the cost of development or a
failure in the design is very high. In other cases, especially for agile development,
you can avoid big design upfront (BDUF). 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 principle is sometimes known as YAGNI
("You ain’t gonna need it").
– Ananth Ramasamy Meenachi www.msarm.com