Your SlideShare is downloading. ×
Same Patterns, Different Architectures
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Same Patterns, Different Architectures


Published on

Same Patterns, Different Architectures

Same Patterns, Different Architectures

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Confused me staring at my codeS.O.L.I.D PrinciplesGOF PatternsOOP Design PrincipleArchitectural Patterns
  • 2. Key Objectives• Business Requirement to design pattern , How dowe implement ?• Do I really need to know All– design patterns ?– Architectural Patterns ?• Understand Pattern Relationships and how theyhave evolved.
  • 3. • What is OOP ?• What is a Design Patterns ?• What is Software Architecture ?
  • 4. Still I cannot imagine why I wrotesoftware like this
  • 5. Why fail to understand ProductArchitecture ?1. Business Architecture (Goals Objectives)2. Business Design (Branding / Sales …)3. Profit Making Business1. System /Technical Architecture2. Technical Design3. Technical Implementation (Code)1. Usability Architecture2. Usability Design3. Useful software ProductLack of collaborationbetween User/Business/ Engineering
  • 6. StrategyProfitsGoalsMarketing & BrandingCustomer AcquisitionRequirementsSystem, Architectural
  • 7. 1. Technical Architecture2. System Design3. 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 officeCountry 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)
  • 11. Filling the Blank - Design• BOTTOM UP :Code > Design > Architecture , Business Usecases(Architecturally Significant)• TOP Down :Architecture/Business Use cases > Design >Code• Combination of both (Moreconvenient and practical)ArchitecturalFunctionalBridgetheDesignGap
  • 12. PerceivedUnderstanding(Can differ fromperson to person)General designGuidelines which areparadigm SpecificSolutions torecurrent designs(Very ContextSpecific)1. S.O.L.I.D Design Principles2. OOP Design Principles(Abstraction, Encapsulation, Inheritance, Polymorphism …)1. GOF Design Patterns2. GRASP Design Patterns3. SOA Patterns …4. Security Patterns
  • 13. Values: How I perceive OOP when Iwas a student
  • 14. Principles: OOP Principles• Abstraction• Encapsulation• Inheritance• Polymorphism
  • 15. Inheritance (IS – A)AssociationRealize/Implementation DependencyAggregation (Has – A)Composition (Has – A)
  • 16. Patterns: Solutions to recurrent designissues(Based on principles){Other Principles …}Assembling Patterns1. GOF Patterns2.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: Architecturallysignificant use cases (Scenarios)• Thin functional Slice : To cover end to endintegration of application layer in a functionalscenario. Functional Significant use case
  • 20. 123451. Client2. Service Layer3. Back officeImplementation/Layering4. Service IntegrationLayer5. Scheduled ThirdParty ServicesSynchronizationDiscuss About What is ArchitecturallySignificant
  • 21. User Stories• As a Banking user– Register new Customer– Unregister Customer– Modify Customer details– Enable Customer Services (SLT, CEB , Coop-City …)– Balance Inquiry
  • 22. Realization of Functionally SignificantUser Story
  • 23. Interaction DiagramsResponsibilities - CRCResponsibilityDriven Designing123
  • 24. GRASP (General ResponsibilityAssignment Software Patterns )Guide line for assigning responsibilities
  • 25. ControllerBundle UI Eventwith Use cases
  • 26. System Use case for CRBThis system use case run on a scheduler
  • 27. High Cohesion /Low Coupling• Epics -> Stories• Refactor -> Complex Objects• Refactor APIs into Segregated APIS• Introduce Workflows into Aggregate APIs intoProcess , User Stories• Introduce mediators to minimize couplingbetween objects
  • 28. Layering ApplicationCommonDBFrameworkCommonServiceHelpersUnit TestsModulesCustomerCustomer DALCustomer ServicePaymentPayment DALPayment ServiceAdminAdmin DALAdmin ServiceModulesCustomer APICustomer APIProxyPayment APIPayment APIProxyAdmin APIAdmin APIProxyDesktop Client Web Client Mobile Client
  • 29. Customer ServiceContracts/Operation Contracts
  • 30. Customer Service Implementation
  • 31. Top level View of Customer Module1231 Customer module Data AccessLayerCommands : Data Access LogicDTO : Data Transfer ObjectsFacades : Data Access Abstractionsto simplify Data access Operations2 Customer Service Interface andImplementationsService Implementation: Servicelogic implementationService Interface: Service andOperation Contracts3 Customer module Unit TestsUnit tests for Customer module.
  • 32. Customer Service Low Level Design
  • 33. User of GOF Patterns in GRASP Process• Creational Patterns• Behavioral Patterns• Structural Patterns
  • 34. Object Creation1) Avoid Multiple new Statements(Singleton Patterns)2) Hide the creation details frombusiness logic3) Create Product families
  • 35. Object Interaction