Your SlideShare is downloading. ×
  • Like
Application Architecture by Lars-Erik Kindblad, Capgemini
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Application Architecture by Lars-Erik Kindblad, Capgemini

  • 3,076 views
Published

 

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
3,076
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
66
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Application ArchitectureLars-Erik KindbladSenior ConsultantBlog: kindblad.com
  • 2. Poor Architecture Project ProgressFeatures Delivered Time | Sector, Alliance, Offering
  • 3. Good Architecture Project ProgressFeatures Delivered Time | Sector, Alliance, Offering
  • 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. Some Important Concepts & Principles Layered Architecture Maintainable code Testable code | Sector, Alliance, Offering
  • 6. LAYERED ARCHITECTURE | Sector, Alliance, Offering
  • 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. LOGICAL LAYER ARCHITECTURE | Sector, Alliance, Offering
  • 9. 3-Layer Architecture | Sector, Alliance, Offering
  • 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. 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. 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. 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. Domain Service Also known as Business Services, Business Managers etc. Business logic that does not belong within an entity | Sector, Alliance, Offering
  • 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. 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. 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. Domain Model | Sector, Alliance, Offering
  • 19. Domain Model | Sector, Alliance, Offering
  • 20. Progress | Sector, Alliance, Offering
  • 21. Infrastructure – Fetch Customer | Sector, Alliance, Offering
  • 22. Infrastructure – Fetch Accounts | Sector, Alliance, Offering
  • 23. Progress | Sector, Alliance, Offering
  • 24. Domain Service – Build a Complete Customer | Sector, Alliance, Offering
  • 25. Progress | Sector, Alliance, Offering
  • 26. Use Case 1: Show the result to the user | Sector, Alliance, Offering
  • 27. Progress | Sector, Alliance, Offering
  • 28. Use Case 2: Return the result through a Web Service | Sector, Alliance, Offering
  • 29. Completed | Sector, Alliance, Offering
  • 30. Visual Studio Project Structure | Sector, Alliance, Offering
  • 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. PHYSICAL TIER ARCHITECTURE | Sector, Alliance, Offering
  • 33. 2-Tier Windows Client Architecture | Sector, Alliance, Offering
  • 34. 3-Tier Windows Client Architecture | Sector, Alliance, Offering
  • 35. 3-Tier Web Architecture | Sector, Alliance, Offering
  • 36. 4-Tier Architecture | Sector, Alliance, Offering
  • 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. MAINTAINABLE CODE | Sector, Alliance, Offering
  • 39. Maintainable Code Important to write code that is easy to maintain – Many enterprise systems can be around for decades | Sector, Alliance, Offering
  • 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. 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. A Typical Class 5 responsibilities, 4 too many… | Sector, Alliance, Offering
  • 43. … Converted into 5 Classes with 1 Responsibility Each | Sector, Alliance, Offering
  • 44. TESTABLE CODE | Sector, Alliance, Offering
  • 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. 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. Traditional CodeInversion of Control using Dependency Injection | Sector, Alliance, Offering
  • 48. Traditional CodeInversion of Control Code | Sector, Alliance, Offering
  • 49. Traditional Code | Sector, Alliance, Offering
  • 50. Inversion of Control using Dependency Injection | Sector, Alliance, Offering
  • 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. Inversion of Control Container Manual approach Using an IOC Container | Sector, Alliance, Offering
  • 53. QUESTIONS? | Sector, Alliance, Offering
  • 54. www.capgemini.comThe information contained in this presentation is proprietary. ©2010 Capgemini. All rights reserved