This document discusses software architecture and design patterns. It begins by outlining key objectives like mapping business requirements to design patterns and understanding pattern relationships. It then defines concepts like object-oriented programming, design patterns, and software architecture. The remainder of the document discusses filling in the gaps between architecture and design, perceived understanding versus principles and patterns, and an example banking architecture with layers and modules.

1. Same Patterns Different
Architectures
Samudra Kanankearachchi
Software Architect

2. Confused me staring at my code
S.O.L.I.D Principles
GOF Patterns
OOP Design Principle
Architectural Patterns

3. 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.

4. • What is OOP ?
• What is a Design Patterns ?
• What is Software Architecture ?

5. Still I cannot imagine why I wrote
software like this

6. Why fail to understand Product
Architecture ?
1. Business Architecture (Goals Objectives)
2. Business Design (Branding / Sales …)
3. Profit Making Business
1. System /Technical Architecture
2. Technical Design
3. Technical Implementation (Code)
1. Usability Architecture
2. Usability Design
3. Useful software Product
Lack of collaboration
between User/
Business/ Engineering

7. Strategy
Profits
Goals
Marketing & Branding
Customer Acquisition
Requirements
System, Architectural

8. 1. Technical Architecture
2. System Design
3. Code (Implementation)
Focus for this session

9. Example Business Case

10. Architecture Vs Design

11. 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 Modes
Web /Mobile/Desktop client ..
• How Does bank connect with Third Party like SLT/ CEB/ Coop-City
Get the billing Data at periodical intervals (No real time requirement)

12. 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
BridgetheDesignGap

13. 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 Principles
2. OOP Design Principles
(Abstraction
, Encapsulation
, Inheritance
, Polymorphism …)
1. GOF Design Patterns
2. GRASP Design Patterns
3. SOA Patterns …
4. Security Patterns

14. Values: How I perceive OOP when I
was a student

15. Principles: OOP Principles
• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

16. Inheritance (IS – A)Association
Realize/Implementation Dependency
Aggregation (Has – A)
Composition (Has – A)

17. Patterns: Solutions to recurrent design
issues(Based on principles)
{Other Principles …}
Assembling Patterns
1. GOF Patterns
2.GRASP Patterns
…

18. Knowing patterns is good enough ?
• No , You have to have a way to apply ?
• Where do we start ?
• How do I do it ?

19. Pattern applying process

20. 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

21. 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

23. User Stories
• As a Banking user
– Register new Customer
– Unregister Customer
– Modify Customer details
– Enable Customer Services (SLT, CEB , Coop-City …)
– Balance Inquiry

24. Realization of Functionally Significant
User Story

25. Interaction Diagrams
Responsibilities - CRC
Responsibility
Driven Designing1
2
3

26. GRASP (General Responsibility
Assignment Software Patterns )
Guide line for assigning responsibilities

27. Controller
Bundle UI Event
with Use cases

28. System Use case for CRB
This system use case run on a scheduler

29. 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

31. Layering Application
Common
DB
Framework
Common
Service
Helpers
Unit Tests
Modules
Customer
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

32. Customer Service
Contracts/Operation Contracts

33. Customer Service Implementation

34. Top level View of Customer Module
1
2
3
1 Customer module Data Access
Layer
Commands : Data Access Logic
DTO : Data Transfer Objects
Facades : Data Access Abstractions
to simplify Data access Operations
2 Customer Service Interface and
Implementations
Service Implementation: Service
logic implementation
Service Interface: Service and
Operation Contracts
3 Customer module Unit Tests
Unit tests for Customer module.

35. Customer Service Low Level Design

36. User of GOF Patterns in GRASP Process
• Creational Patterns
• Behavioral Patterns
• Structural Patterns

37. Object Creation
1) Avoid Multiple new Statements
(Singleton Patterns)
2) Hide the creation details from
business logic
3) Create Product families