PRINCIPLES OF SOFTWARE ARCHITECTUREIN RELATION TO TYPO3

TYPO3

CAMP

MÜNCHEN

11.9.2016

GERNOT SCHULMEISTER

Lives in Mönchengladbach

Developes websites with TYPO3 since Version 3.7

(2005)

Works for TeamWFP

Has a migration background and comes from

Southeast-Europe (Austria)

Likes operative CMS evaluations, Big Data,

Software Architecture, TYPO3 Events

facebook.com/gernot.schulmeister

twitter.com/mistakanista1

SEITE 2

SCHEDULE

Definition

Tasks of an architect

Process of development

Design principles

Architecture styles

Architecture patterns

The fundamental organization of a

software system embodied in its

components, their relationships to

each other and to the

environment and the principles

guiding its design and evolution

DEFINITION

TASKS: ARCHITECTS

Construct, design and implement

Evaluate, decide and consult

Grant the fulfillment of requirements

Document

Communicate and are diplomats and acrobats

Simplify

Make assumptions and preconditions explicit

Need courage

SEITE 5

PROCESS OF ARCHITECTURE DEVELOPMENT

SEITE 6

STEPS

Gather information

Clarify requirements: core tasks, category of system,

quality targets, relevant stakeholders, business and

technical context

Investigate influences and side conditions

Develop solution strategies

Design and communicate

Accompany implementation

SEITE 7

ARCHITECTURE DEVELOPMENT

SEITE 9

DESIGN PRINCIPLES

SEITE 10

HEURISTICS

Mix top-down, bottom-up & outside in strategies

hierarchical composition & decomposition

Separation of concerns (encapsulation)

Information hiding & small interfaces

Regular refactoring & redesign

Separation of business & technical aspects

Expect changes & switch the perspective

Use core functions?

SEITE 11

BROKEN CORE FUNCTIONS 6.2 - 7

TCA Filters in backend modules

Field selection in backend modules

Backend Links and Actions (Delete, Hide)

Pagination & Sorting

Submit and button values in POST array missing

Selected value of select boxes in array

Hooks and XClasses

Preselect tab in record

Date field interaction with custom calendar

SEITE 12

TECHNIQUES FORA GOOD DESIGN

Loose coupling (number of relations of a block)

High cohesion (put together what belongs together)

Open closed principle (closed to changes, open for

extensions)

Don´t repeat yourself

Inversion of control (dependency injection)

Expect errors and failures (failure first)

Liskov substitution principle (a subclass always

substitute the base class)

SEITE 13

SEITE 14

RESOLVE CYCLICDEPENDENCIES

ARCHITECTURE STYLES

SEITE 15

DOMAIN DRIVEN DESIGN

SEITE 17

OTHERS

MDA Model driven architecture: generate code from

UML

SOA Service oriented architecture: Service directory,

provider & consumer is a business topic

Microservices Modularisation also concerning

hardware and live operation, orchestration decentral

without middleware

SEITE 18

ARCHITECTURE PATTERNS

SEITE 19

MVC MODEL VIEW CONTROLLER

Model holds the data

View presents the data

Controller processes user events,

executes business logic and

updates views

SEITE 20

MVP MODEL VIEW PRESENTER

Based on MVC strict separation of

model & view

Model holds the data and the

business logic

View: no logic only receives the user input

Presenter: connects view with model and

controls the logical process

SEITE 21

MVVM – MODEL VIEWVIEWMODEL

By angular, based on MVC

The view-model connects the model with the

view and adds presentation logic

Loads additional data, updates the GUI

SEITE 22

PRESENTATION ABSTRACTION CONTROL

SEITE 24

FROM CHAOSTO STRUCTURE

Layer architecture

Pipes & filters: filters process data, pipes transport

intermediate results decoupling in many ways

Used in compiler, parser, image processing

Blackboard: specialized knowledge sources send

possible solutions of a problem to the blackboard to

find an overall solution

Used in image and language recognition, system

surveillance

SEITE 25

SEITE 26

DISTRIBUTED SYSTEMS

Broker: imparts between client & server

Server sends service interface to broker

Broker finds service for the client and connects the request and

response

CQRS Command Query Responsibility Segregation

Separates commands (data changes) from Queries (reading access

to data)

Good for parallel executions without dependencies

Commands: ACID transactions

Queries idempotent

CONCLUSION

Every developer is also a little architects

Basic architecture knowledge is useful for every

developer

Architecture knowledge helps to understand TYPO3

better

SEITE 27