LimeSurvey architecture

This is the main public document for LimeSurvey's architecture

Overview

todo, constraints

This is the architectural documentation for the LimeSurvey application. It does not document the ecosystem surrounding it.

The architectural round trip should look like this:

Risk analysis --> quality attributes priority --> architectural decisions

This document should be reviewed, updated and discussed at least yearly.

Vision

todo

Technology stack

Programming languages:

• PHP 7.2+
• JavaScript ES6 (admin) and IE11 compatible (survey taking)
• CSS, HTML
• XML, JSON

Frameworks:

• Yii 1.1
• jQuery
• Vue 1
• PHPUnit

Tools:

• Git
• GitHub Actions
• Psalm
• CodeSniffer
• MessDetector
• Scrutinizer
• Selenium, geckodriver

Dependency management:

• Manually (should be refactored)
• Yarn
• Composer

Libraries:

• CKEditor
• kcfinder
• PDF?
• Sodium
• Twig
• PHPMailer
• pclzip

Risks

As defined in the code quality guide.

Risk identification, analysis, mitigation, monitor.

todo, probability, impact, supporting knowledge

Product risk

These risks are considering the individual LimeSurvey user or admin.

Possible mitigations are in sub-lists.

Risk	Probability	Impact	Mitigation
Data loss (known)	Low	Medium to high	Unit-tests and integrity tests in the CI
			Internal QA culture
			Possibility to enable extensive logging, from which you can reconstruct answers
Data loss (unknown)			?
Unauthorized data access			Full test-suite of the permission system
Blocking bugs (that could lead to data loss)'			Full test-suite of the high-priority functionality
			Full manual QA testing before each minor release (not for patch releases)

Project risk

Risk	Probability	Impact	Mitigation
Communication	Medium	Low to medium	todo
Regressions	High	Medium to high	Functional testing for each new feature
			Continuous effort to expand the test suit
			Effort to keep an eye on incoming bug reports
			Effort to create bug statistics and improve bug statistics

Business risk

Internal to LimeSurvey GmbH

Quality attributes

Considering the risks above, the most important quality attributes could be considered:

• Testability
• Changeability

They can be improved by using dependency injection, and having clearer separation between the abstraction layers, including splitting the monolith into separate modules.

Function composition and "function core, imperative shell" pattern could also help.

Strategies to improve testability:

• Explicit dependencies
• "Functional core, imperative shell"
• Make testability explicit when designing new features
• Make testability part of refactoring efforts

Views

4+1 view model?

Domain

A simple domain diagram over LimeSurvey:

Source.

Layers

LimeSurvey uses a basic, monolithic MVC layered architecture.

• View layer, serving HTML, JSON or XML to the calling part (can be browser or local API machine)
• Controller layer, gluing parts together from the other layers
• Business logic layer, calculating business rules, should be fully unit-testable
• Database storage layer (also includes domain entity validation)

Refactoring should be focused on strengthening the separation between the layers.

Source.

Overview of future refactoring efforts.

Forbidden transgression between abstraction layers:

How splitting up a monolith into separate modules could look like:

Possible architecture of REST + SPA module:

Class hierarchy

todo

Controller hierarchy

ActiveRecord hierarchy

Extended core classes

Flow and state

automata between states

admin flow diagram? what makes sense to document? create survey process?

API design

todo

Security

todo