Layered Architecture for Social Network Web Site

Knowing that social network application is going to be a large undertaking that should last for some time, we need to design something that can be easily extended as the need arises. For that we will try to design this application with extensibility in mind. The easiest way to do that is to follow the general rule of maintaining "separation of concerns (SoC)".

Layers

The easiest way to maintain SoC is to first break major areas of your application into layers. In most applications, this might be broken down into the presentation, business logic, and data access layers.

• Presentation Layer: This layer would normally hold anything pertaining to the user interface of your application—the buttons, links, and other controls that a user would click on and interact with while using your application.
• Business Logic Layer: This is where the rules of your application would live. This could be as simple as formatting the currency of a price in your product cataloger to something more complex such as enforcing rules regarding data input.
• Services Layer: While building Service Oriented Architecture (SOA), services layer is built on top of the business logic layer.
• Data Access Layer: The data access layer is responsible for connecting to a data source and interacting with the data that is stored in that location. This could be a database, some XML files, text files, or even a web service.
• Utility/Components Layer: Functionalists like mechanisms for caching, logging errors, reading from configuration files, etc. are needed across the application. Such concerns, that cut across application, are referred as cross cutting concerns. To provide implementation to resolve such concerns we create an independent project called Components (also referred as Utility) layer.

In most small applications, just these three layers are good enough as shown:

Three Layers

Tiered architecture

While layers are logical separation of concerns, tiers are used for physical separation. In a tiered approach, one or more layers are hosted on to independent machines/boxes to support fail-over  ensure high availability, and sociability. While architecting an application and planning for growth, this is an essential

consideration.

Domain-driven Design

Domain-driven Design (DDD) is not a methodology, framework, or technology, but more of a way of thinking practically. It is geared towards making software development move at a faster pace. It puts the focus on the domain and domain logic as it is truly the center of any application. Having a robust application and infrastructure wrapped around poorly designed domain logic is a problem waiting to happen for more information here .