Architecture – Software Design Idea for multi tier architecture

Architecture

I am currently investigating multi tier architecture design for a web based application in MVC3. I already have an architecture but not sure if its the best I can do in terms of extendability and performance.

The current architecure has following components

  • DataTier (Contains EF POCO objects)
  • DomainModel (Contains Domain related objects)
  • Global (Among other common things it contains Repository objects for CRUD to DB)
  • Business Layer (Business Logic and Interaction between Data and Client and CRUD using repository)
  • Web(Client) (which talks to DomainModel and Business but also have its own ViewModels for Create and Edit Views for e.g.)

Note: I am using ValueInjector for convering one type of entity to another. (which is proving an overhead in this desing. I really dont like over doing this.)

My question is am I having too many tiers in the above architecure?
Do I really need domain model? (I think I do when I exposes my Business Logic via WCF to external clients).

What is happening is that for a simple database insert it

(1) create ViewModel

(2) Convert ViewModel to DomainModel for Business to understand

(3) Business Convert it to DataModel for Repository and then data comes back in the same order.

Few things to consider,

I am not looking for a perfect architecure solution as it does not exits.
I am looking for something that is scalable.
It should resuable (for e.g. using design patterns ,interfaces, inheritance etc.)
Each Layers should be easily testable.

Any suggestions or comments is much appriciated.

Thanks,

Best Answer

I'll be very general so sorry if it is nothing new for you, I know that's boring:

  • adding a layer adds flexibility but costs some performance
  • adding a layer does not improve scalability (it has to be addressed separately at every layer that creates bottleneck)

I do not know your stack, but similar applications usually consists of database, middleware (domain object with their mapping to database, business logic) and frontend (web interface for humans).

Depending on situation some layers can be merged (embedded database, business logic and frontend as single web app) - that is OK as long as you keep the dependencies clean (no cycles) and you already know where to cut to divide the siamese twins when it becomes necessary.

Related Topic