Software architecture principles in relation with TYPO3 and what might happen if your programming pradigma is "use all the features of the core" and you update from 6.2 to 7.6 LTS

1. PRINCIPLES OF
SOFTWARE
ARCHITECTURE
IN RELATION TO TYPO3
TYPO3
CAMP
MÜNCHEN
11.9.2016

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

3. SCHEDULE
 Definition
 Tasks of an architect
 Process of development
 Design principles
 Architecture styles
 Architecture patterns

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

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

6. PROCESS OF
ARCHITECTURE
DEVELOPMENT
SEITE 6

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

8. ARCHITECTURE
DEVELOPMENT
SEITE 9

9. DESIGN PRINCIPLES
SEITE 10

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

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

12. TECHNIQUES FOR
A 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

13. SEITE 14
RESOLVE CYCLIC
DEPENDENCIES

14. ARCHITECTURE STYLES
SEITE 15

15. DOMAIN DRIVEN DESIGN
SEITE 17

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

17. ARCHITECTURE PATTERNS
SEITE 19

18. MVC MODEL VIEW
CONTROLLER
 Model holds the data
 View presents the data
 Controller processes user events,
executes business logic and
updates views
SEITE 20

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

20. MVVM – MODEL VIEW
VIEWMODEL
 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

21. PRESENTATION
ABSTRACTION CONTROL
SEITE 24

22. FROM CHAOS
TO 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

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

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