Same Patterns Different Architectures - Colombo Architecture Meetup - Session-03

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