Application Architecture by Lars-Erik Kindblad, Capgemini

6,074 views

Published on

Published in: Technology, Business
  • Be the first to comment

Application Architecture by Lars-Erik Kindblad, Capgemini

  1. 1. Application ArchitectureLars-Erik KindbladSenior ConsultantBlog: kindblad.com
  2. 2. Poor Architecture Project ProgressFeatures Delivered Time | Sector, Alliance, Offering
  3. 3. Good Architecture Project ProgressFeatures Delivered Time | Sector, Alliance, Offering
  4. 4. Foundation For Delivering Good Architecture Good communication with the business stakeholders • Meet the needs of the business Understand the business processes • Scale with the business Experience • Simplify | Sector, Alliance, Offering
  5. 5. Some Important Concepts & Principles Layered Architecture Maintainable code Testable code | Sector, Alliance, Offering
  6. 6. LAYERED ARCHITECTURE | Sector, Alliance, Offering
  7. 7. Logical Layers and Physical Tiers A Logically Layer is how you logically divide the code in the application A Physical Tier is how you divide your application into multiple sub- applications that can run on separate servers | Sector, Alliance, Offering
  8. 8. LOGICAL LAYER ARCHITECTURE | Sector, Alliance, Offering
  9. 9. 3-Layer Architecture | Sector, Alliance, Offering
  10. 10. Presentation Layer Also known as Frontend Layer, User Interface (UI) Layer Responsible for creating and displaying the user interface and handling user interaction Data shown is fetched from the Domain Layer | Sector, Alliance, Offering
  11. 11. Service Layer Also known as Web Service Layer Responsible for exposing a web service API and returning the method result as XML or JSON Data returned is retrieved from the Domain Layer | Sector, Alliance, Offering
  12. 12. Domain Layer Also known as Business Layer Responsible for all the business logic in the application Consists of a Domain Model and Domain Services | Sector, Alliance, Offering
  13. 13. Domain Model Also known as Business Model, Business Objects, Entities etc. Responsible for having a model that reflects how the business stakeholders look at the world Consists of entities with relationships and behavior Similar to a database model but a domain model is richer | Sector, Alliance, Offering
  14. 14. Domain Service Also known as Business Services, Business Managers etc. Business logic that does not belong within an entity | Sector, Alliance, Offering
  15. 15. Infrastructure Layer Also known as Data Access Layer, Repository Layer etc. Responsible for querying a database, calling a web service, sending e-mail etc. | Sector, Alliance, Offering
  16. 16. Example We want to create a banking application with customers and related accounts. An account consist of an account number, a balance and a credit limit. If the account has been overdrawn then the account and customer is considered to be “sick”, otherwise “healthy” Use Case 1: As a user I want to see if a customer is healthy or sick Use Case 2: As a user I want to retrieve if a customer is healthy or sick through a web service Technology: .NET, ASP.NET MVC, WCF | Sector, Alliance, Offering
  17. 17. What do we need?1. Domain Model for Customer and Account2. Business logic for deciding if an account and customer is healthy or sick3. 2 Classes: Fetching Customer and fetch list of Accounts from the database4. Service Class for building up a Customer Entity with AccountsUse Case 1:1. MVC Controller and a View to display the health status for a given customerUse Case 2:1. WCF Service for returning whether a customer is healthy or not | Sector, Alliance, Offering
  18. 18. Domain Model | Sector, Alliance, Offering
  19. 19. Domain Model | Sector, Alliance, Offering
  20. 20. Progress | Sector, Alliance, Offering
  21. 21. Infrastructure – Fetch Customer | Sector, Alliance, Offering
  22. 22. Infrastructure – Fetch Accounts | Sector, Alliance, Offering
  23. 23. Progress | Sector, Alliance, Offering
  24. 24. Domain Service – Build a Complete Customer | Sector, Alliance, Offering
  25. 25. Progress | Sector, Alliance, Offering
  26. 26. Use Case 1: Show the result to the user | Sector, Alliance, Offering
  27. 27. Progress | Sector, Alliance, Offering
  28. 28. Use Case 2: Return the result through a Web Service | Sector, Alliance, Offering
  29. 29. Completed | Sector, Alliance, Offering
  30. 30. Visual Studio Project Structure | Sector, Alliance, Offering
  31. 31. Why should you have many layers? Less code per layer Reduced complexity Easier to maintain code Easier to add new functionality Easier to test Allows for reuse code across the application | Sector, Alliance, Offering
  32. 32. PHYSICAL TIER ARCHITECTURE | Sector, Alliance, Offering
  33. 33. 2-Tier Windows Client Architecture | Sector, Alliance, Offering
  34. 34. 3-Tier Windows Client Architecture | Sector, Alliance, Offering
  35. 35. 3-Tier Web Architecture | Sector, Alliance, Offering
  36. 36. 4-Tier Architecture | Sector, Alliance, Offering
  37. 37. Why have many tiers? Reuse logic across applications Improve security, e.g. restrict database access for the client by going through a service Improved performance, the performance critical tiers can be scaled across multiple servers | Sector, Alliance, Offering
  38. 38. MAINTAINABLE CODE | Sector, Alliance, Offering
  39. 39. Maintainable Code Important to write code that is easy to maintain – Many enterprise systems can be around for decades | Sector, Alliance, Offering
  40. 40. Follow a Coding Standard The Team should decide on, write down and follow a strict coding standard Be consistent on how you name classes, methods, variables etc. Be consistent on what architectural patterns to use, when to use it and how to structure the code = Cleaner code, easier to read and maintain | Sector, Alliance, Offering
  41. 41. Single Responsibility Principle (SRP) A Class should only have 1 responsibility • Preferably only one public method • Small in size, preferably no longer than 1 screen size = Easier to: • Read • Maintain • Change • Test | Sector, Alliance, Offering
  42. 42. A Typical Class 5 responsibilities, 4 too many… | Sector, Alliance, Offering
  43. 43. … Converted into 5 Classes with 1 Responsibility Each | Sector, Alliance, Offering
  44. 44. TESTABLE CODE | Sector, Alliance, Offering
  45. 45. 2 Main Types of Testing Integration Testing • Top to bottom testing Unit Testing • Test a single class without it’s dependencies using Inversion of Control | Sector, Alliance, Offering
  46. 46. Inversion of Control Inversion of Control = IOC Make code loosely coupled Make unit testing possible How? Move creation of dependencies outside the class they are being used in A better name - Inversion of Dependency Creation | Sector, Alliance, Offering
  47. 47. Traditional CodeInversion of Control using Dependency Injection | Sector, Alliance, Offering
  48. 48. Traditional CodeInversion of Control Code | Sector, Alliance, Offering
  49. 49. Traditional Code | Sector, Alliance, Offering
  50. 50. Inversion of Control using Dependency Injection | Sector, Alliance, Offering
  51. 51. Inversion of Control Container A framework that can automatically create a given type with all the required dependencies Popular frameworks for .NET • Unity • Castle Windsor • Ninject • StructureMap • etc. | Sector, Alliance, Offering
  52. 52. Inversion of Control Container Manual approach Using an IOC Container | Sector, Alliance, Offering
  53. 53. QUESTIONS? | Sector, Alliance, Offering
  54. 54. www.capgemini.comThe information contained in this presentation is proprietary. ©2010 Capgemini. All rights reserved

×