,Architecture Patterns
• guide system design based on scalability, agility and business needs
• define basic characteristics and behavior of an application
Monolithic —> single deployment unit (e.g. layered, modular monolith)
Distributed —> multiple units (e.g. microservices, event-driven)
Layered Architecture
Single deployment unit with functionality grouped by technical categories
Structure:
• Closed layers: presentation —> business —> persistence —> database
• Separation of concerns —> each layer handles specific logic
Components within a specific layer deal only with logic that pertains to that layer
Pros:
• simple, low cost, easy testing
• ideal for technical changes
Cons:
• poor scalability/ performance (tight coupling)
• Hard to deploy (full redeploy for small changes)
Use case:
Banking app
Layers:
• UI layer —> shows account information to the user
• Business Logic layer —> calculates balances, checks rules
• Persistence layer —> reads/ writes data to UserAccounts table in the database
• Database —> stores the actual data
Closed layer —> a request moves from layer to layer, it must go through the layer right below it to get to the next layer
below that one
Why not allow the presentation layer direct access to either the persistence layer or database layer?
Violates separation of concerns
if the UI directly queries the database —> business logic may be bypasses (no fraud checks), UI developers must
understand database schemas, breaking modularity
Tight coupling
closed layers ensure changes in one layer don’t ripple to others
ex: changing database schema would force UI updates if it directly accesses the DB
Security Risks
exposed data —> direct DB access might expose sensitive fields to the UI
no gatekeeping —> business layers enforce security —> risks unauthorized actions
Layers of isolation concept —> changes made in one layer of the architecture generally don’t impact or affect components
in other layers
each layer is independent of the other layers —> having little or no knowledge of the inner workings of other layers
each
, Open layers
• shared-services layer —> common service components accessed
by components within the business layer
• Service layer —> open —> requests are allowed to bypass this open layer
and go directly to the layer below it
• Cheap and easy to use
• Bad maintainability, testability, deployability, elasticity, scalability,
fault-tolerance, evolvability
Black arrows —> request flowing down to the databases to retrieve the
Customer data
Red arrows —> response flowing back up to the screen to display the data
Presentation Layer
• customer screen —> responsible for accepting request and displaying the
customer information
• once it receives the request —> forwards it onto the customer delegate module —> responsible for knowing which
modules in the business layer can process that request and how to get to that module and what data it needs
Business layer
• customer object module —> aggregating all the information needed by the business request (customer info) —> calls
out to the customer dao (data access object) module in the persistence layer to get customer data and calls order
dao module to get order information
Persistence Layer
• customer dao and order dao —> in turn execute SQL statements —> retrieve corresponding data —> pass it back up
to the customer object in the business layer —> aggregates the data —> passes that info back up to the customer
delegate —> passes that data to the customer screen —> present to user
Easy of deployment —> LOW (for larger applications)
Testability —> HIGH (because specific layers)
Performance —> LOW (inefficiencies of having to go through multiple layers of the architecture to fulfill a request)
Scalability —> LOW (tightly coupled and monolithic implementations)
Easy of development —> HIGH (well known pattern, easy to implement)
• guide system design based on scalability, agility and business needs
• define basic characteristics and behavior of an application
Monolithic —> single deployment unit (e.g. layered, modular monolith)
Distributed —> multiple units (e.g. microservices, event-driven)
Layered Architecture
Single deployment unit with functionality grouped by technical categories
Structure:
• Closed layers: presentation —> business —> persistence —> database
• Separation of concerns —> each layer handles specific logic
Components within a specific layer deal only with logic that pertains to that layer
Pros:
• simple, low cost, easy testing
• ideal for technical changes
Cons:
• poor scalability/ performance (tight coupling)
• Hard to deploy (full redeploy for small changes)
Use case:
Banking app
Layers:
• UI layer —> shows account information to the user
• Business Logic layer —> calculates balances, checks rules
• Persistence layer —> reads/ writes data to UserAccounts table in the database
• Database —> stores the actual data
Closed layer —> a request moves from layer to layer, it must go through the layer right below it to get to the next layer
below that one
Why not allow the presentation layer direct access to either the persistence layer or database layer?
Violates separation of concerns
if the UI directly queries the database —> business logic may be bypasses (no fraud checks), UI developers must
understand database schemas, breaking modularity
Tight coupling
closed layers ensure changes in one layer don’t ripple to others
ex: changing database schema would force UI updates if it directly accesses the DB
Security Risks
exposed data —> direct DB access might expose sensitive fields to the UI
no gatekeeping —> business layers enforce security —> risks unauthorized actions
Layers of isolation concept —> changes made in one layer of the architecture generally don’t impact or affect components
in other layers
each layer is independent of the other layers —> having little or no knowledge of the inner workings of other layers
each
, Open layers
• shared-services layer —> common service components accessed
by components within the business layer
• Service layer —> open —> requests are allowed to bypass this open layer
and go directly to the layer below it
• Cheap and easy to use
• Bad maintainability, testability, deployability, elasticity, scalability,
fault-tolerance, evolvability
Black arrows —> request flowing down to the databases to retrieve the
Customer data
Red arrows —> response flowing back up to the screen to display the data
Presentation Layer
• customer screen —> responsible for accepting request and displaying the
customer information
• once it receives the request —> forwards it onto the customer delegate module —> responsible for knowing which
modules in the business layer can process that request and how to get to that module and what data it needs
Business layer
• customer object module —> aggregating all the information needed by the business request (customer info) —> calls
out to the customer dao (data access object) module in the persistence layer to get customer data and calls order
dao module to get order information
Persistence Layer
• customer dao and order dao —> in turn execute SQL statements —> retrieve corresponding data —> pass it back up
to the customer object in the business layer —> aggregates the data —> passes that info back up to the customer
delegate —> passes that data to the customer screen —> present to user
Easy of deployment —> LOW (for larger applications)
Testability —> HIGH (because specific layers)
Performance —> LOW (inefficiencies of having to go through multiple layers of the architecture to fulfill a request)
Scalability —> LOW (tightly coupled and monolithic implementations)
Easy of development —> HIGH (well known pattern, easy to implement)
