N-Layer Architecture

Question

I'm in the situation that I have to design and implement a system from the scratch. I have some questions about the architecture that I would like your comments and thoughts on.

Quick Info about the project: It's a data centric web application.

The application will be built on Microsoft .NET Framework 4.0 with MS SQL SERVER 2008 database.

Requirement:

1. Rich UI and robust
2. Multi-device support (every browser and on every device)
3. Loosely coupled

Below is the architectural diagram I have built:

Briefing of the architecture

1. Presentation layer : HTML5/ASP.NET MVC + JQuery (Web application for multi-device support in first version)
2. Distributed Services : WCF (XML/JSON/JSONP)
3. Domain Layer(Business Layer) : All business logic
4. Data persistence (DAL Layer) : Entity Framework 4.0 with database first approach. POCO entities are generated and separated out using T4 template
5. Infrastructural Layer: Contains common libraries like POCO entities, Exception Handling, logging etc

My Concerns :

1. As application is to be built loosely coupled so in future if business requirement grows new modules can be easily plugged in without affecting the architecture. So I thought of using the Repository pattern along with IoC and DI (can be Unity/Ninject/Sprint.NET or any other)
2. WCF with both XML and JSON support
3. Distributed Service Layer to place IoC & DI
4. Exception Handling & Logging using Enterprise Library 5.0

Looking for valuable comments and suggestions. If I am doing anything wrong please put me in right direction.

Superorder

FYI - 'Tier' and 'Layer' are not equivalent terms. Layer refers to logical seperation as you described. Tier usually refers to physical seperation of hardware eg Database server, Web server. – Dreda

Just out of curiosity, what software did you use to create the diagram? – Corncob

I am using Visual Studio 2010 (Ultimate Edition) – Superorder

Answer 1

I would suggest the following comment: right from the outset your approach will create tight coupling. This goes directly against your requirement #3 "Loosely coupled"

In your diagram you have defined two modules. Main module, and Module 2. I would guess that these two modules are quite distinct from each other. What I mean by this is that you could develop them completely separately and then plug them in, because the business concerns they address are different.

However, your current architectural approach:

• Couples Main Module and Module 2 data into the same database
• Couples Main Module and Module 2 business objects into the same business layer
• Couples Main Module and Module 2 services into the same service layer
• Couples the deployment and management of Main Module and Module 2

What may be worth considering: Build Main Module and Module 2 as separate vertical service stacks.

What I mean is Main Module and Module 2 become Main Service and Service 2

Each service has it's own database, it's own business layer, it's own services layer and it's own UI components.

However, this raises the concern: how can Main Service and Service 2 both work together to create my product?

To address this:

1. At the UI end, you stitch your front end together by using client-side code to load responses from the Main Service and Service 2 into one view.

2. At the back end you use publish subscribe messaging to allow Main Service to subscribe to events happening in Service 2 and vice versa.

This will result in an application built from the ground up on top of loosely coupled vertical service stacks, which maintain consistency by the asynchronous exchange of messages.

If you then need to add in a new module to your application, you can create a new service stack which supports the desired capability and wire it up with little or even no change needed to the other stacks (ideally the only reason to change existing stacks would be that they want to subscribe to events from the new module).

It's a very different approach to the one you're suggesting, but one which allows you to meet the requirement for loose coupling better, in my opninion.

Alidia

Hello thanks for the suggestion.Will you mind briefing more about"Each service has it's own database,its own business layer..UI components". – Superorder

These are separate concerns which can be applied when developing your service stacks. In my opinion IOC has very little to do with solution design, more of a technical architecture thing. – Alidia

My main point is this. Why plan to couple your various functions together into one application? If two sections of your application are vertically different then they should be planned, developed, deployed, and managed as separate concerns. – Alidia

Most of this is lifted wholesale from Udi Dahan's talk (the vimeo link in my first comment above). He explains it all better than me – Alidia

Answer 2

It makes sense that the WPF, WinForm etc UIs should call the WCF layer. I'm assuming that it's a business requirement to have multiple UIs, otherwise if you can only have one UI a responsive web UI is the most flexible choice.

However, I don't think your MVC UI needs to use the WCF layer. It could call the domain layer directly. That would be faster and remove a pointless layer.

Obviously, that would only work so long as you don't put any logic in your WCF layer. And the WCF layer really shouldn't have any logic in it.

You also state that you want to place IoC & DI in the Distributed Service Layer. That doesn't make much sense in terms of your MVC UI. You'll need to use DI in the MVC project so you can unit test the controllers.

Deforest

In this case the WCF services would make up the application layer, ie the platform that all the UI's build upon. It would be a mistake for one UI to bypass this layer. – Dreda

Not at all, if the domain layer has all the logic and the WCF layer is just a facade it makes sense to bypass the WCF layer when a call to it is pointless. – Deforest

There is more logic required than what is in the domain layer. The application layer should encapsulate the various transactions that make up the platform, and coordinate a workflow of units of logic which exist in the domain layer. – Dreda

The WCF layer (you're calling it the application layer), doesn't include business logic - see point 3 - "Domain Layer(Business Layer) : All business Logic". The WCF layer is a web interface for thick clients, it doesn't need to be used (unless there are unstated requirement) for a thin client like an html UI. What is the logic you think is required in the WCF layer? – Deforest

see martinfowler.com/eaaCatalog/serviceLayer.html. Specifically "coordinates the application's response in each operation.". This is the point where it's invoking a sequence of operations in the domain model. These workflows are a vital piece of the application and shouldn't be bypassed. – Dreda

But coddey's domain layer is the service layer. His WCF layer is a facade. See martinfowler.com/eaaCatalog/remoteFacade.html. Otherwise, he wouldn't have specified that the business logic is in the domain layer. Do you want to see logic in both the WCF and domain layer? – Deforest

I'm not talking about WCF at all. From your original response "remove *a pointless layer" I assumed you were advocating the UI's communicating directly with the domain model - which would result in huge duplication of transaction logic in each UI. I think we can agree that there does need to be a service/application layer (whether it has facades in WCF, ServiceStack or whatever) – Dreda

Ok good, I think we agree then. No direct calling, always using a servic layer. :) Glad we cleared that up. Not that anyone else probably cares now, have a good morning! :) – Deforest

I think our misunderstanding is a hint to the OP that his architecture is a little vague ;) – Dreda

Answer 3

How come that the architecture diagram doesn't use the domain layer for ASP.NET?

It seems to me that you may be overarchitecturing your application. Also, while it looks great to support 6 (or so) different front-end technologies, the effort to maintain all of them will be horrendous. I'd stick to one technology for the front-end - most likely HTML5 with client-side MVC or similar.

Peridot

Answer 4

Looking at your diagram I have a couple of points I'm not clear on:

• Where is the domain model? Domain Core or the 'model' in the persistence layer?
• How does the domain layer interact with the data access layer? The interaction is not as clear as between the service/application layer and domain layer.
• What the difference between a repository in the domain layer and a repository in the data access layer? I usually make the distinction of having 'model repositories' in the domain layer which act upon domain model objects, and 'data gateways' in the data access layer which act upon DTO's.
• What is domain core? Is this the implementation of the application layer transactions?
• Does there need to be a further abstraction of the persistence framework? (EF)

Dreda

1.Domain Layer is Business Layer consists pure Business Logic's. – Superorder

POCO entities placed in infrastructure layer are Models without any logic. Domain layer has direct dependency(as of now, do you know any other approach) – Superorder

I would suggest switching from an anemic domain model (en.wikipedia.org/wiki/Anemic_domain_model) to a rich domain model. – Dreda

Here's a link to a google cache of the wikipedia article since they're blacked out: webcache.googleusercontent.com/… – Dreda