1. Application Architecture
Lars-Erik Kindblad
Senior Consultant
Blog: kindblad.com

2. Poor Architecture
Project Progress
Features Delivered
Time
| Sector, Alliance, Offering

3. Good Architecture
Project Progress
Features 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 Account
2. Business logic for deciding if an account and customer is healthy or
sick
3. 2 Classes: Fetching Customer and fetch list of Accounts from the
database
4. Service Class for building up a Customer Entity with Accounts
Use Case 1:
1. MVC Controller and a View to display the health status for a given
customer
Use 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 Code
Inversion of Control using Dependency Injection
| Sector, Alliance, Offering

48. Traditional Code
Inversion 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.com
The information contained in this presentation is proprietary. ©2010 Capgemini. All rights reserved