1

2
Why are you here?
LEARN TO HAVE
MORE FUN

THE CLASSIC
A /layouts folder from hell
One Visual Studio solution with
one Visual Studio project
3

4
3 / n tiers architecture
A DIFFERENT
ARCHITECTURAL
APPROACH
PRESENTATION
LOGIC
DATA

 Changing requirements, support and hotfixes
generates technical debt
 The impact of technical debt increase over time
 The costs of adding new features increase over
time
 Software rots
COST OF MAINTENANCE
5
Cost
Time

 Changing requirements, support and hotfixes
generates technical debt
 The impact of technical debt increase over time
 The costs of adding new features increase over
time
 Software rots
COSTS OF MAINTENANCE
6
Cost
Time

Component Architecture á la Pentia
7

8
CREDITS

Theoretical Foundation
9

“Depend in the direction of stability” – Uncle Bob
A stable piece of code is one where its interface does
not change over time.
Code in a customer domain is expected to change
over time hence is less stable.
Instable code is not bad but a reality.
 New requirements always occur in a domain
implementation
 Design and layout are always instable
 Instable code should always be easy to change or
even replace
STABLE DEPENDENCY PRINCIPLE
10
INSTABLE
FLEXIBLE
STABLE

“The dependencies between components must not
form cycles” – Uncle Bob
Enforced by Visual Studio between projects but still
possible
 Not working with strict layering
 Sitecore templates
 Using the same field in several components
 Misusing IoC containers
 Textual dependencies
The devil lies in soft cyclic dependencies
ACYCLIC DEPENDENCIES PRINCIPLE
11
Component A
Component B
Component C

“The classes in a component is reused together. If you
reuse one of the classes in a component, you reuse
them all” – Uncle bob
EXAMPLE:
 You need class A from component X in component
Y.
 Class A relies on class B and C in the same
component
 When class B or C changes so does class A
meaning that even though you only need class A
you are dependent on B and C as well
THE COMMON REUSE PRINCIPLE
12

THE COMMON CLOSURE PRINCIPLE (CCP)
“The classes in a component should be closed
together against the same kinds of changes. A
change that affects a component affects all the
classes in that component and no other components.”
– Uncle Bob
SINGLE RESPONSIBILITY PRINCIPLE (SRP)
“A class should have only one reason to change.”
– Uncle Bob
A class should only have one responsibility
THE COMMON CLOSURE PRINCIPLE
13
CCP is SRP on Component level
All classes within the same concept
that are likely to change for the same
reason should be in the same
component

MORE THEORY?
14

COMPONENT ARCHITECTURE
15
Component
Component
Component
Component
Component

16

Time for
examples
17

18

19

20

21

SERVING

23

FOUND A BUG?
 It does not ruin your whole dish
 Throw it out or keep it confined
24

WANT TO LEARN
MORE? CONTACT…
Anders Laub Christoffersen
Sitecore MVP, Junior Partner
alc@pentia.dk
http://laubplusco.net
@anderslaub
Pentia A/S
Zeppelinerhallen
Islands Brygge 55
2300 København S
25

26