Menu
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:
Below is the architectural diagram I have built:
Briefing of the architecture
My Concerns :
Looking for valuable comments and suggestions. If I am doing anything wrong please put me in right direction.
519
An N-tier architecture divides an application into logical layers and physical tiers. Layers are a way to separate responsibilities and manage dependencies. Each layer has a specific responsibility. A higher layer can use services in a lower layer, but not the other way around.
N-Tier refers to the actual n system components of your application. On the other hand, N-Layers refer to the internal architecture of your component. N-Tier architecture usually has atleast three separate logical parts, each located on separate physical server. Each tier is responsible for a specific functionality.
Although the layered architecture pattern does not specify the number and types of layers that must exist in the pattern, most layered architectures consist of four standard layers: presentation, business, persistence, and database (Figure 1-1).
When it comes to n-tier architecture, a three-tier architecture is fairly common. In this setup, you have the presentation or GUI tier, the data layer, and the application logic tier.
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:
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:
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.
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.
104
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.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
