same patterns different architectures - colombo architecture meetup - session-03
TRANSCRIPT
Same Patterns Different Architectures
Samudra KanankearachchiSoftware Architect
Confused me staring at my code
S.O.L.I.D Principles
GOF Patterns
OOP Design Principle
Architectural Patterns
Key Objectives
• Business Requirement to design pattern , How do we implement ?
• Do I really need to know All – design patterns ?
– Architectural Patterns ?
• Understand Pattern Relationships and how they have evolved.
• What is OOP ?
• What is a Design Patterns ?
• What is Software Architecture ?
Still I cannot imagine why I wrote software like this
Why fail to understand Product Architecture ?
1. Business Architecture (Goals Objectives)2. Business Design (Branding / Sales …)3. Profit Making Business
1. System /Technical Architecture2. Technical Design 3. Technical Implementation (Code)
1. Usability Architecture2. Usability Design3. Useful software Product
Lack of collaboration between User/
Business/ Engineering
StrategyProfits
Goals
Marketing & Branding
Customer Acquisition
Requirements
System, Architectural Concerns
1. Technical Architecture2. System Design3. Code (Implementation)
Focus for this session
Example Business Case
Architecture Vs Design
Architectural
• Is all banks has good telephone & Internet coverage ? Majority , Yes they have fairly good internet.
• User capacity ? Average 100 to 2000 customers a bank.
• How branches are located in the country? Around 10 – 15 branches in each district,
• Each district has a head office Country head offices are located in Colombo.
• Users Connectivity ModesWeb /Mobile/Desktop client ..
• How Does bank connect with Third Party like SLT/ CEB/ Coop-CityGet the billing Data at periodical intervals (No real time requirement)
Filling the Blank - Design
• BOTTOM UP :Code > Design > Architecture , Business Use cases(Architecturally Significant)
• TOP Down :Architecture/Business Use cases > Design > Code
• Combination of both (More convenient and practical)
Architectural
Functional
Bri
dge
th
e D
esig
n G
ap
Perceived Understanding(Can differ from person to person)
General design Guidelines which are paradigm Specific
Solutions to recurrent designs (Very Context Specific)
1. S.O.L.I.D Design Principles2. OOP Design Principles
(Abstraction , Encapsulation , Inheritance , Polymorphism …)
1. GOF Design Patterns2. GRASP Design Patterns 3. SOA Patterns …4. Security Patterns
Values: How I perceive OOP when I was a student
Principles: OOP Principles
• Abstraction
• Encapsulation
• Inheritance
• Polymorphism
Inheritance (IS – A)Association
Realize/Implementation Dependency
Aggregation (Has – A)Composition (Has – A)
Patterns: Solutions to recurrent design issues(Based on principles)
{Other Principles …}
Assembling Patterns 1. GOF Patterns2.GRASP Patterns…
Knowing patterns is good enough ?
• No , You have to have a way to apply ?
• Where do we start ?
• How do I do it ?
Pattern applying process
Minimal Viable First release
• Proof of Concepts for: Architecturally significant use cases (Scenarios)
• Thin functional Slice : To cover end to end integration of application layer in a functional scenario. Functional Significant use case
12345
1. Client
2. Service Layer
3. Back office Implementation /Layering
4. Service Integration Layer
5. Scheduled Third Party Services Synchronization
Discuss About What is Architecturally Significant
User Stories
• As a Banking user
– Register new Customer
– Unregister Customer
– Modify Customer details
– Enable Customer Services (SLT, CEB , Coop-City …)
– Balance Inquiry
Realization of Functionally Significant User Story
Interaction Diagrams
Responsibilities - CRC
Responsibility Driven Designing1
2
3
GRASP (General Responsibility Assignment Software Patterns )
Guide line for assigning responsibilities
ControllerBundle UI Event with Use cases
System Use case for CRB
This system use case run on a scheduler
High Cohesion /Low Coupling
• Epics -> Stories
• Refactor -> Complex Objects
• Refactor APIs into Segregated APIS
• Introduce Workflows into Aggregate APIs into Process , User Stories
• Introduce mediators to minimize coupling between objects
Layering Application
CommonDB
FrameworkCommon Service Helpers
Unit Tests
ModulesCustomer
Customer DAL
Customer Service
Payment
Payment DAL
Payment Service
Admin
Admin DAL
Admin Service
Modules
Customer API
Customer API Proxy
Payment API
Payment API Proxy
Admin API
Admin API Proxy
Desktop Client Web Client Mobile Client
Customer Service Contracts/Operation Contracts
Customer Service Implementation
Top level View of Customer Module
1
2
3
1 Customer module Data Access LayerCommands : Data Access LogicDTO : Data Transfer ObjectsFacades : Data Access Abstractions to simplify Data access Operations
2 Customer Service Interface andImplementations Service Implementation: Service logic implementation
Service Interface: Service and Operation Contracts
3 Customer module Unit TestsUnit tests for Customer module.
Customer Service Low Level Design
User of GOF Patterns in GRASP Process
• Creational Patterns
• Behavioral Patterns
• Structural Patterns
Object Creation
1) Avoid Multiple new Statements (Singleton Patterns)
2) Hide the creation details from business logic
3) Create Product families