Same Patterns, Different Architectures


Published on

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

No notes for slide

Same Patterns, Different Architectures

  1. 1. Confused me staring at my codeS.O.L.I.D PrinciplesGOF PatternsOOP Design PrincipleArchitectural Patterns
  2. 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. 3. • What is OOP ?• What is a Design Patterns ?• What is Software Architecture ?
  4. 4. Still I cannot imagine why I wrotesoftware like this
  5. 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. 6. StrategyProfitsGoalsMarketing & BrandingCustomer AcquisitionRequirementsSystem, Architectural
  7. 7. 1. Technical Architecture2. System Design3. Code (Implementation)Focus for this session
  8. 8. Example Business Case
  9. 9. Architecture Vs Design
  10. 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. 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. 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. 13. Values: How I perceive OOP when Iwas a student
  14. 14. Principles: OOP Principles• Abstraction• Encapsulation• Inheritance• Polymorphism
  15. 15. Inheritance (IS – A)AssociationRealize/Implementation DependencyAggregation (Has – A)Composition (Has – A)
  16. 16. Patterns: Solutions to recurrent designissues(Based on principles){Other Principles …}Assembling Patterns1. GOF Patterns2.GRASP Patterns…
  17. 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. 18. Pattern applying process
  19. 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. 20. 123451. Client2. Service Layer3. Back officeImplementation/Layering4. Service IntegrationLayer5. Scheduled ThirdParty ServicesSynchronizationDiscuss About What is ArchitecturallySignificant
  21. 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. 22. Realization of Functionally SignificantUser Story
  23. 23. Interaction DiagramsResponsibilities - CRCResponsibilityDriven Designing123
  24. 24. GRASP (General ResponsibilityAssignment Software Patterns )Guide line for assigning responsibilities
  25. 25. ControllerBundle UI Eventwith Use cases
  26. 26. System Use case for CRBThis system use case run on a scheduler
  27. 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. 28. Layering ApplicationCommonDBFrameworkCommonServiceHelpersUnit TestsModulesCustomerCustomer DALCustomer ServicePaymentPayment DALPayment ServiceAdminAdmin DALAdmin ServiceModulesCustomer APICustomer APIProxyPayment APIPayment APIProxyAdmin APIAdmin APIProxyDesktop Client Web Client Mobile Client
  29. 29. Customer ServiceContracts/Operation Contracts
  30. 30. Customer Service Implementation
  31. 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. 32. Customer Service Low Level Design
  33. 33. User of GOF Patterns in GRASP Process• Creational Patterns• Behavioral Patterns• Structural Patterns
  34. 34. Object Creation1) Avoid Multiple new Statements(Singleton Patterns)2) Hide the creation details frombusiness logic3) Create Product families
  35. 35. Object Interaction