Application Architecture by Lars-Erik Kindblad, Capgemini

Application Architecture

Lars-Erik Kindblad
Senior Consultant
Blog: kindblad.com

Poor Architecture

Project Progress
Features Delivered

Time

| Sector, Alliance, Offering

Good Architecture

Project Progress
Features Delivered

Time


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


Some Important Concepts & Principles

 Layered Architecture
 Maintainable code
 Testable code


LAYERED ARCHITECTURE


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


LOGICAL LAYER ARCHITECTURE


3-Layer Architecture


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


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


Domain Layer
 Also known as Business Layer

 Responsible for all the business logic in the application
 Consists of a Domain Model and Domain Services


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


Domain Service
 Also known as Business Services, Business Managers etc.

 Business logic that does not belong within an entity


Infrastructure Layer
 Also known as Data Access Layer, Repository Layer etc.

 Responsible for querying a database, calling a web service, sending
e-mail etc.


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


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

Domain Model


Progress


Infrastructure – Fetch Customer


Infrastructure – Fetch Accounts


Domain Service – Build a Complete Customer


Use Case 1: Show the result to the user


Use Case 2: Return the result through a Web Service


Completed


Visual Studio Project Structure


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


PHYSICAL TIER ARCHITECTURE


2-Tier Windows Client Architecture


3-Tier Windows Client Architecture


3-Tier Web Architecture


4-Tier Architecture


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


MAINTAINABLE CODE


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 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


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


A Typical Class

 5 responsibilities, 4 too many…


… Converted into 5 Classes with 1 Responsibility Each


TESTABLE CODE


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


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


Traditional Code

Inversion of Control using Dependency Injection


Traditional Code

Inversion of Control Code


Traditional Code


Inversion of Control using Dependency Injection


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.


Inversion of Control Container

Manual approach

Using an IOC Container


QUESTIONS?


Application Architecture by Lars-Erik Kindblad, Capgemini

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Application Architecture by Lars-Erik Kindblad, Capgemini

Semelhante a Application Architecture by Lars-Erik Kindblad, Capgemini (20)

Último

Último (20)

Application Architecture by Lars-Erik Kindblad, Capgemini