This talk will present a structured approach for setting up a Sitecore solution that follows a component based architecture. The architecture is based on a combined hundreds of years of Sitecore experience at Pentia, the founders of Sitecore. Besides presenting the architectural principles, the talk will stir up a discussion about what really is Sitecore best practices when it comes to solution design. The target audience for this talk is both developers that are new to Sitecore and those who have years of experience. Everyone who has had basic Sitecore training can benefit from attending this presentation.

1. 1

2. 2
Why are you here?
LEARN TO HAVE
MORE FUN

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

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

5.  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

6.  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

7. Component Architecture á la Pentia
7

8. 8
CREDITS

9. Theoretical Foundation
9

10. “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

11. “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

12. “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

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

14. MORE THEORY?
14

15. COMPONENT ARCHITECTURE
15
Component
Component
Component
Component
Component

16. 16

17. Time for
examples
17

18. 18

19. 19

20. 20

21. 21

22. SERVING

23. 23

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

25. 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. 26