Slides from my talk on application architecture and clean code.

1. Application Architecture
2014
Lars-Erik Kindblad
Senior Consultant
& Head Of Microsoft
Community Of Practice

2. Feature Delivery For Most Software Projects
Project Progress
• Complex and messy code
• Code and logic is duplicated
• No common coding standard
• No strict architecture
• ++

3. Ideal Feature Delivery
Project Progress

4. Agenda
Testable code
 Inversion of Control
Maintainable code with less duplication
 Single Responsibility Principle
 Extract Method Principle
 Execute Around Method Pattern
Well structured code
 Onion Architecture & N-Layered Architecture
 Ways to group and structure code
Reduce bugs
 Event Sourcing & replaying events

5. Inversion Of Control
Make code loosely coupled
Make unit testing possible

6. Traditional Code

7. Inversion Of Control

8. Traditional code
Main class UserCreator
CreateUser
DbCommand
1. Creates
2. Creates
Inversion of control code
Main class
UserCreator
CreateUser
DbCommand
Dependency
1. Creates
2. Creates with
object from 1.
Dependency

9. Dependency Injection - Constructor Injection

10. Dependency Injection - Interface Injection

11. Dependency Injection - Setter Injection

12. Static Service Locator

13. Injected Service Locator

15. Which Patterns To Use

16. Traditional Code

17. Dependency Injection - Constructor Injection

18. Dependency Injection - Interface Injection

19. Dependency Injection - Setter Injection

20. Static Service Locator

21. Injected Service Locator

22. When To Use Which
Patterns

23. Always Use Dependency Injection – Constructor Injection
...except

24. Facade Classes

25. Dependency Injection

26. Service Locator

27. Loops

28. Dependency Injection

29. Service Locator

30. Base Classes

31. Dependency Injection

32. Service Locator

33. Unknown Types At Compile Time

34. Service Locator

35. Summary
Constructor Injection Injected Service Locator
Facade classes
(WCF Services,
MVC Controllers)
X
Loops X X
Base classes X
Unknown types at
compile time
X
All other scenarios X

36. Inversion Of Control (IOC) Container
A framework that can automatically create an instance of a given type with
all the required dependencies
Popular frameworks
 Unity, Castle Windsor, Ninject, StructureMap etc.
Manual approach
Using an IOC container

37. Configuration
Must register what types the container can resolve
Types are registered with a life time manager
 PerContainer – Container.Resolve<UserCreator> returns the same UserCreator instance
every time (Singleton)
 Transient – Container.Resolve<UserCreator> returns a new UserCreator instance every
time
 PerRequest – Container.Resolve<UserCreator> returns the same UserCreator instance
within a web request
Configuration can be done through
 XML – Read from the .config file. Bad practice, too limiting
 Code – Register all types through code
• Auto registration – Automatically register types based on conventions e.g. all types in assembly x

38. Where To Plugin
An IOC container should be created and initialized in the presentation
layer or or above (DependencyResolution layer)
Any other layer should NOT have a reference to the IOC container
Presentation
Domain
Database, Web Service,
Queue, SMTP server etc.
Infrastructure
Don’t reference
container here
Don’t reference
container here
Should reference
and use container

39. Unity Example 1/3

40. Unity Example 2/3

41. Unity Example 3/3

42. Summary
Use an IOC Container to create type instances when using inversion of
control
Only the presentation layer should know about the IOC Container
Configuration: Prefer code over xml
Use auto registration to reduce configuration code

43. Single Responsibility Principle
Single Responsibility Principle = SRP
1 of the 5 SOLID principles
”A class or module should have one, and only one, reason to change”
 A class should do one thing
 A class should have only one responsibility
Max 100-200 lines of code per class?
The benefits
 Easier to give the class a good name
 Easier to read
 Easier to maintain & extend
 Easier to test

44. The God Object
A God object is an object that knows too much or does too much
The opposite of the SRP

45. Single Responsibility Objects

46. Current responsibilities:
• Facade class
• Input validation
• Talks to a database
• Sends e-mail

47. Refactored To SRP
UserManager
CreateUser
GetUser
DeleteUser

48. Refactored UserManager
Responsibility
• Facade class

49. Refactor GetUser & DeleteUser
Responsibility
• Return the user from the
database
Responsibility
• Delete the user from the
database

50. Refactored to CreateUser
Responsibility
• Input validation
• Create the user in the
database
• Send confirmation e-mail

51. Future Refactoring
Split into multiple classes when the code increases in size
CreateUser
CreateUserDbCommand
SendEmailConfirmation

52. Summary
A class following the single responsibility principle is a class that does only
one thing and has only one reason to change
The opposite of SRP is a God-object
Benefits
 Easy to give the class a good name
 Less code per class means
• Reduced complexity = less errors
• Easier to maintain & extend
• Easier to test
Can use the Facade pattern if a special API is required

53. Code Duplication – Example #1
Duplicated code

54. Extract Method Principle - Refactored

55. Code Duplication – Example #2
Duplicated code

56. Execute Around Method Pattern - Refactored

57. Execute Around Method - Example #2

58. Domain
Model
Domain Services
Presentation
Application Services
Infrastructure
Frameworks and external
endpoint integrations
Onion Architecture
 A layer can only depend on
inner layers
 Frameworks and
infrastructure concerns are
pushed to the outer layer
 A change of framework will
not affect the application
core
Application business rules
= use cases
Enterprise business rules
Database, Web Service,
Queue, SMTP server etc.
Application Core

59. Onion Architecture Flattened
Presentation
Application Services
Domain Services
Database, Web Service,
Queue, SMTP server etc.
Domain
Model
Infrastructure

60. The Use Case – Open New Account
Create new account in database
and return account number
Is personal number empty?
Is the customer credit worthy?
Return error
No
Yes
Yes
No

61. Dependency Resolution
Domain
Model
Domain Services
Presentation
Application Services
Infrastructure
AccountController
Database
Onion Architecture – Open New Account Use Case
• OpenNewAccountUseCase
• ICreateAccountCommand
CreateAccount-
DbCommand
• CreditCheckService
• IGetTotalDebtForCustomerQuery
Web service
GetTotalDebtForCustomer-
ServiceAgent
ExecuteUseCase

62. Process Flow
AccountController
OpenNewAccountUseCase
CreateAccountDbCommand
CreditCheckService
GetTotalDebtForCustomer-
ServiceAgent
ExecuteUseCase
DependencyResolver Unity IOC Container
Database
Web service
• Transaction management
• Exception handling
• Logging
Insert/Update/Delete = *Command
Read = *Query

69. Alternatives – 3-Layered Architecture
Where are the use cases?
Presentation
Domain Services
Domain
Model
Database, Web Service,
Queue, SMTP server etc.
Infrastructure

70. Alternatives – 4-Layered Architecture
Must always go through domain
layer – domain layer will get
non-domain code
All return types from Domain
Services or Infrastructure must
be declared in the Domain
Model
Presentation
Application Services
Domain Services
Domain
Model
Database, Web Service,
Queue, SMTP server etc.
Infrastructure

71. Alternatives – 4-Layered Architecture – Non-Strict
The application- and domain
logic is tightly coupled to the
infrastructure
 Domain Centric vs Data Centric
architecture
Presentation
Application Services
Domain Services
Domain
Model
Database, Web Service,
Queue, SMTP server etc.
Infrastructure

72. The Use Cases
Open new account
View accounts
Latest transactions
Single payment
Multiple payments
International payment
View Executed payments
View policies
Change address
Change payment limit

73. Group Into Components
Account
• Open new
account
• View
accounts
• Latest
transactions
Payments
• Single
payment
• Multiple
payments
• International
payment
• View
Executed
payments
Insurance
• View
policies
Settings
• Change
address
• Change
payment
limit

74. Package By Layer
Application Services
• Account
• Open new account
• OpenNewAccountUseCase
• ICreateAccountCommand
Domain Services
• Account
• Open new account
• CreditCheckService
• IGetTotalDebtForCustomerQuery
...

75. Package By Component
Account
• Application Services
• Open new account
• OpenNewAccountUseCase
• ICreateAccountCommand
• Domain Services
• Open new account
• CreditCheckService
• IGetTotalDebtForCustomerQuery
• ...
Payments
• Application Services
• ...

76. Package By Feature
Account
• Open new account
• OpenNewAccountUseCase
• ICreateAccountDbCommand
• CreditCheckService
• IGetTotalDebtForCustomerQuery
• ...
Payments
• ...

77. Change Request Comparison
Package by layer
 Must change code in multiple projects
Package by component
 Must change code in 1 project but multiple folders
Package by feature
 Must change code in 1 project, one folder

78. Event Sourcing
ExecuteUseCase: _log.UseCase(useCaseInput) generates a stream of
executed use cases/events
A use case should either be a command or a query
Serialized data Execution date Status
OpenNewAccountInput 3. march Successful
ChangeAddressInput 4. march Successful
OpenNewAccountInput 7. march Successful
ChangePaymentLimitInput 10. march Failed
ChangePaymentLimitInput 11. march Successful

79. Replay Use Cases/Events
Stream of use cases/events can be replayed
 Test the system for errors
 Restore from failure
How to replay? Make an application that
1. Delete all the data in the database
2. Read first event in log
3. Resolve use case class from use case input
4. Execute use case
5. Read next event and goto 23.

80. Summary
Use Inversion of Control to write testable and loosely coupled code
Use Single Responsibility Principle to write small, easy to maintain classes
Use Extract Method Principle & Execute Around Method pattern to reduce
code duplication
Use the Onion Architecture or N-Layer to get a fixed architecture
Package by Layer-, Component- or Feature to get well organized code
Log executed use cases and replay them before a new release to check
for bugs

81. The information contained in this presentation is proprietary.
© 2014 Capgemini. All rights reserved.
www.capgemini.com