SharePoint Served: Architectural Style

Architecture styles and patterns as sets of principles that shape an application. This following table describes and discusses architecture styles and principles commonly used for applications today. For each style, you will find an overview, with example and information that will help you choose the appropriate architectural styles for your application

Category	Architecture styles	Description	Example
Deployment	Client/Server	Segregates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures.	When a bank customer accesses online banking services with a web browser (the client), the client initiates a request to the bank's web server. The customer's login credentials may be stored in a database, and the web server accesses the database server as a client. An application server interprets the returned data by applying the bank's business logic, and provides the output to the web server. Finally, the web server returns the result to the client web browser for display. In each step of this sequence of client–server message exchanges, a computer processes a request and returns data. This is the request-response messaging pattern. When all the requests are met, the sequence is complete and the web browser presents the data to the customer. Source: https://en.wikipedia.org/wiki/Client%E2%80%93server_model Consider the client/server architectural style if: Your application is server-based and will support many clients. You are creating Web-based applications exposed through a Web browser. You are implementing business processes that will be used by people throughout the organization. You are creating services for other applications to consume. You want to centralize data storage, backup, and management functions. Your application must support different client types and different devices.
Deployment	N-Tier / 3-Tier	Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.	In the web development field, three-tier is often used to refer to websites, commonly electronic commerce websites, which are built using three tiers: A front-end web server serving static content, and potentially some cached dynamic content. In web based application, Front End is the content rendered by the browser. The content may be static or generated dynamically. A middle dynamic content processing and generation level application server (e.g., ASP.NET, Ruby on Rails, Django (web framework), Laravel, Spring Framework, CodeIgniter, Symfony, Flask (web framework)) A back-end database or data store, comprising both data sets and the database management system software that manages and provides access to the data. Consider the 3-tier architectural style if: You are developing an intranet application where all servers are located within the private network. You are developing an Internet application, and security requirements do not restrict implementing business logic within the public-facing Web or application server. Consider using more than three tiers if: Security requirements dictate that business logic cannot be deployed to the perimeter network. The application makes heavy use of resources and you want to offload that functionality to another server
Structure	Component-Based Architecture	Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.	An individual software component is a software package, a web service, a web resource, or a module that encapsulates a set of related functions (or data). You already have suitable components, or can obtain suitable components from third-party suppliers. Pluggable architecture e.g., financial applications or business software, Salesforce’s Lightning Design System. Consider the component-based architectural style if: You already have suitable components, or can obtain suitable components from third-party suppliers. Your application will predominantly execute procedural-style functions, perhaps with little or no data input. You want to be able to combine components written in different code languages. You want to create a pluggable architecture that allows you to easily replace and update individual components.
	Object-Oriented	A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behaviour relevant to the object.	E.g. system of the automatic teller machine, an order processing application Consider the object-oriented architectural style if: You want to model the application based on real-world objects and actions. You already have suitable objects and classes that match the design and operational requirements. You need to encapsulate logic and data together in reusable components. You have complex business logic that requires abstraction and dynamic behaviour.
	Layered Architecture	Partitions the concerns of the application into stacked groups (layers).	E.g. 1. Line of business (LOB) applications, such as accounting and customer-management systems. 2. Enterprise Web-based applications and Web sites. 3. Application for restaurant The main actors are: the customer, the waiter and the Chef They all have different responsibilities. It is good idea to build your site / application using Layered architecture if following principles are met Have clear separation of responsibilities — each layer being only responsible for itself Exposed workflow — as opposed to the spaghetti code we’ve all see way too many times Ability to replace one or several layers implementation with minimum effort and side effects. Your application is complex, and the high-level design demands separation so that teams can focus on different areas of functionality. You want to implement complex and/or configurable business rules and processes. Your application must support different client types and different devices.
Communication	Message Bus	An architecture style that prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other.	D-Bus is an open source unix-based tool for inter process communication (IPC) that utilizes the message bus architecture. D-Bus was designed to address communication between applications in the same desktop session, and between a desktop session and the operating system. D-Bus uses both the call-and-return and event-based varieties of message passing [19] between applications to facilitate these concerns Consider the message-bus architectural style if: You have existing applications that interoperate with each other to perform tasks. You are implementing a task that requires interaction with external applications. You are implementing a task that requires interaction with applications hosted in different environments. You have existing applications that perform specific tasks, and you want to combine those tasks into a single operation.
Communication	Service-Oriented Architecture (SOA)	Refers to applications that expose and consume functionality as a service using contracts and messages.	E.g. Amazon's code base API (Amazon Web Service) which respond to web requests. Reservation system (Starwood Hotels and Resorts) Sharing of medical data (Harvard Medical School) Consider the SOA style if: You have access to suitable services, or can purchase suitable services exposed by a hosting company. You want to build applications that compose a variety of services into a single UI. You are creating Software plus Services (S+S), Software as a Service (SaaS), or cloud-based applications. You need to support message-based communication between segments of the application. You need to expose functionality in a platform-independent way. You want to take advantage of federated services, such as authentication. You want to expose services that are discoverable through directories and can be used by clients that have no prior knowledge of the interfaces. You want to support interoperability and integration.
Domain	Domain Driven Design	An object-oriented architectural style focused on modelling a business domain and defining business objects based on entities within the business domain.	E.g. Project Silk, Home loan processing system Consider the DDD style if: You are developing software of extremely high essential complexity (with a lot of correlated business rules). And/or software with clear future, where the Domain Model can outlast the infrastructure where the business requirements change fast