Application ArchitectureLars-Erik KindbladSenior ConsultantBlog: kindblad.com
Poor Architecture                         Project ProgressFeatures Delivered                                Time          ...
Good Architecture                         Project ProgressFeatures Delivered                                Time          ...
Foundation For Delivering Good Architecture       Good communication with the business stakeholders    •    Meet the need...
Some Important Concepts & Principles   Layered Architecture   Maintainable code   Testable code                        ...
LAYERED ARCHITECTURE                       | Sector, Alliance, Offering
Logical Layers and Physical Tiers A Logically Layer is how you logically divide the code in the  application A Physical ...
LOGICAL LAYER ARCHITECTURE                             | Sector, Alliance, Offering
3-Layer Architecture                       | Sector, Alliance, Offering
Presentation Layer Also known as Frontend Layer, User Interface (UI) Layer Responsible for creating and displaying the u...
Service Layer Also known as Web Service Layer Responsible for exposing a web service API and returning the  method resul...
Domain Layer Also known as Business Layer Responsible for all the business logic in the application Consists of a Domai...
Domain Model Also known as Business Model, Business Objects, Entities etc. Responsible for having a model that reflects ...
Domain Service Also known as Business Services, Business Managers etc. Business logic that does not belong within an ent...
Infrastructure Layer Also known as Data Access Layer, Repository Layer etc. Responsible for querying a database, calling...
Example We want to create a banking application with customers and related  accounts. An account consist of an account nu...
What do we need?1. Domain Model for Customer and Account2. Business logic for deciding if an account and customer is healt...
Domain Model               | Sector, Alliance, Offering
Domain Model               | Sector, Alliance, Offering
Progress           | Sector, Alliance, Offering
Infrastructure – Fetch Customer                                  | Sector, Alliance, Offering
Infrastructure – Fetch Accounts                                  | Sector, Alliance, Offering
Progress           | Sector, Alliance, Offering
Domain Service – Build a Complete Customer                                             | Sector, Alliance, Offering
Progress           | Sector, Alliance, Offering
Use Case 1: Show the result to the user                                          | Sector, Alliance, Offering
Progress           | Sector, Alliance, Offering
Use Case 2: Return the result through a Web Service                                               | Sector, Alliance, Offe...
Completed            | Sector, Alliance, Offering
Visual Studio Project Structure                                  | Sector, Alliance, Offering
Why should you have many layers?   Less code per layer   Reduced complexity   Easier to maintain code   Easier to add ...
PHYSICAL TIER ARCHITECTURE                             | Sector, Alliance, Offering
2-Tier Windows Client Architecture                                     | Sector, Alliance, Offering
3-Tier Windows Client Architecture                                     | Sector, Alliance, Offering
3-Tier Web Architecture                          | Sector, Alliance, Offering
4-Tier Architecture                      | Sector, Alliance, Offering
Why have many tiers? Reuse logic across applications Improve security, e.g. restrict database access for the client by g...
MAINTAINABLE CODE                    | Sector, Alliance, Offering
Maintainable Code Important to write code that is easy to maintain – Many enterprise  systems can be around for decades  ...
Follow a Coding Standard The Team should decide on, write down and follow a strict coding  standard Be consistent on how...
Single Responsibility Principle (SRP) A Class should only have 1 responsibility  • Preferably only one public method  • S...
A Typical Class 5 responsibilities, 4 too many…                                           | Sector, Alliance, Offering
… Converted into 5 Classes with 1 Responsibility Each                                                | Sector, Alliance, O...
TESTABLE CODE                | Sector, Alliance, Offering
2 Main Types of Testing Integration Testing  • Top to bottom testing Unit Testing  • Test a single class without it’s de...
Inversion of Control   Inversion of Control = IOC   Make code loosely coupled   Make unit testing possible   How? Move...
Traditional CodeInversion of Control using Dependency Injection                                                  | Sector,...
Traditional CodeInversion of Control Code                            | Sector, Alliance, Offering
Traditional Code                   | Sector, Alliance, Offering
Inversion of Control using Dependency Injection                                             | Sector, Alliance, Offering
Inversion of Control Container A framework that can automatically create a given type with all the  required dependencies...
Inversion of Control Container         Manual approach      Using an IOC Container                                 | Secto...
QUESTIONS?             | Sector, Alliance, Offering
www.capgemini.comThe information contained in this presentation is proprietary. ©2010 Capgemini. All rights reserved
Upcoming SlideShare
Loading in...5
×

Application Architecture by Lars-Erik Kindblad, Capgemini

3,665

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,665
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
74
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×