Requirements

Function Requirements

These are your use-cases. For example, for a e-commerce site, you may need to offer functionality like: search inventory, place order and review past orders.

Non-Functional Requirements

How should the system behave.

These are requirements like:

• usability
• reliability
• efficiency
• scalability
• maintainability

Restrictions

Restrictions limit your options.

Restrictions include: 

• compliance
• costs
• standards
• time to market

Priorities

We need to prioritize functional and non-functional requirements based on restrictions.

For example: may not prioritize portability if we control where the solution is to be deployed.

Implementation

Key Concepts

• Start with one thing at a time.
• Keep it simple. (KISS)
• Don't over engineer. You ain't gonna need it. (YAGNI)

Software Architecture Patterns

See O'Reillys - Software Architecture Patterns

Layered Architecture Pattern

Components within the layered architecture pattern are organized into horizontal layers, each layer performing a specific role within the application (e.g., presentation logic or business logic). Although the layered architecture pattern does not specify the number and types of layers that must exist in the pattern, most layered architec‐ tures consist of four standard layers: presentation, business, persistence, and database.

A request originating from the presentation layer must first go through the business layer and then to the persistence layer before finally hitting the database layer.

While closed layers facilitate layers of isolation and therefore help isolate change within the architecture, there are times when it makes sense for certain layers to be open. For example, suppose you want to add a shared-services layer to an architecture containing com‐ mon service components accessed by components within the busi‐ ness layer (e.g., data and string utility classes or auditing and logging classes). Creating a services layer is usually a good idea in this case because architecturally it restricts access to the shared services to the business layer (and not the presentation layer). Without a separate layer, there is nothing architecturally that restricts the presentation layer from accessing these common services, making it difficult to govern this access restriction.

Pattern Analysis

Overall agility Rating: Low Analysis: Overall agility is the ability to respond quickly to a constantly changing environment. While change can be isolated through the layers of isolation feature of this pattern, it is still cumbersome and time-consuming to make changes in this architecture pattern because of the monolithic nature of most implementations as well as the tight coupling of components usually found with this pattern.

Ease of deployment Rating: Low Analysis: Depending on how you implement this pattern, deployment can become an issue, particularly for larger applica‐ tions. One small change to a component can require a redeployment of the entire application (or a large portion of the application), resulting in deployments that need to be planned, scheduled, and executed during off-hours or on weekends. As such, this pattern does not easily lend itself toward a contin‐ uous delivery pipeline, further reducing the overall rating for deployment.

Performance Rating: Low Analysis: While it is true some layered architectures can per‐ form well, the pattern does not lend itself to high-performance applications due to the inefficiencies of having to go through multiple layers of the architecture to fulfill a business request.

Scalability Rating: Low Analysis: Because of the trend toward tightly coupled and mon‐ olithic implementations of this pattern, applications build using this architecture pattern are generally difficult to scale. You can scale a layered architecture by splitting the layers into separate physical deployments or replicating the entire application into multiple nodes, but overall the granularity is too broad, making it expensive to scale.

Event Driven Architecture

Example

...

References