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


Published on

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 - Colombo Architecture Meetup - Session-03

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