following component architecture in sitecore solutions - anders laub @ sugcon 2015

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

5C

ost

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

6C

ost

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

Co

mp

on

en

t

Co

mp

on

en

t

Co

mp

on

en

t

Co

mp

on

en

t

Co

mp

on

en

t

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 ChristoffersenSitecore MVP, Junior Partner

alc@pentia.dk

http://laubplusco.net

@anderslaub

Pentia A/SZeppelinerhallen

Islands Brygge 55

2300 København S

25

26