The document discusses software architecture and design patterns. It begins by describing the author's confusion with their code and lists objectives like understanding how to implement patterns and architectural relationships. It then defines concepts like object-oriented programming, design patterns, and software architecture. The remainder discusses filling gaps between architecture and design, perceived understanding versus guidelines, and examples of applying minimal viable products, layering, and design patterns like GOF patterns to a banking system.

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

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

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

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

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

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

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

8. Example Business Case

9. Architecture Vs Design

10. 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)

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

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

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

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

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

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

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

18. Pattern applying process

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

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

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

23. Realization of Functionally Significant
User Story

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

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

26. Controller
Bundle UI Event
with Use cases

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

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

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

31. Customer Service
Contracts/Operation Contracts

32. Customer Service Implementation

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

34. Customer Service Low Level Design

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

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

37. Object Interaction