Software Architecture and Content Management

One of the biggest architecture decision which stares us on our face is whether to use OR mapping or not. The arguments in favour are very convincing, but does it apply in all scenario?

Read the rest of this entry »

Software architects are a confused lot. Communicating with each other is a challenge. There is always a discussion about what goes in what layer ( or tier) and logical vs Physical separation. Even the definition of Data Tier specially is open to interpretation.

Arnon is the first person I saw calling (potential) physical separation as Tier and (Definitely) logical separation as layer - and I believe its a good separation to have in our vocabulary. Read the rest of this entry »

Every few days, in one forum or the other, I see the question “How to choose between a component and a service” or “shall I make this module a component or a service” or some variation of it. Is there a simple answer? Read the rest of this entry »

No Design =

==>shock  & Mess

Programming Styles:

Sequential:

Structured:

OO

Rules of Design:

Optimal solution, not best. There are tradeoffs.

Lots of Common sense. Remember - nothing is intuitive, programming is not a primal instinct but people do as trained ( I struggled to eject CD from a MAC - who said they are more intuitive than windows). Dont expect VB programmers to apply OO principles by default.

Important principles

Single Responsibility Principle:

A class should have only one Responsibility, or only one reason for change.

 Multiple responsibility

= Confusion

and greater impact of maintenance 

(Imagine, if this stone was in Europe and needed signs as well - this will require changing the unchanged sign as well - to get space.

Interface Seggregation principle

Many, specific interfaces are better than one generic.

  is better than  

Why? One change has greater impact (  remoulding)

Addition can be tricky - Imagine 8 interfaces -you cant insert it!!.

Avoid Duplicate code.

Duplication = maintenance nightmare, chances of mistakes. 

Open Close Principle:

Open for extension, closed for modification.

If not, each change will have ripple effect.

Dependency Inversion Principle.

Abstraction should not depend on detail.

= Isolation of layers = maintenability.

Acyclic dependancy.

Anti-Patterns

Silver bullet / swiss Army knife.

Remember:

Re-factoring is easy. So Prototype, build , improve. Dont attempt to tick features off in one step.

Agile methodology says: Dont design for Unknown Future Requirements.

Keep it simple!