Architectural decision records

From LimeSurvey Manual

Revision as of 14:44, 21 June 2021 by Ollehar (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The purpose of this page is to keep a record of large technical decision, to track their progress and rational.


The template for an architectural decision is as follows [1]:

In the context of <use case/user story u>, facing <concern c> we decided for <option o> and neglected <other options>, to achieve <system qualities/desired consequences>, accepting <downside d/undesired consequences>, because <additional rationale>.


todo, definition of done,

Add new decisions at the top.

Date Author Topic Decision
2021-06-16 Olle Haerstedt Fat models In the context of fat models, facing lack of testability, we decided to move code to dependency injected service classes to achieve higher testability with unit-tests, accepting that readability might be slightly reduced (circular coupling between new service classes and old models, at least temporarily), because preventing regressions is more important right now.
2021-06-16 Olle Haerstedt New features In the context of new features, facing high degree of regressions, we decided to always add integrity tests to new features to prevent regressions and ensure adherence to specification, accepting that we might need to help external contributors with scaffolding and guidance, also accepting the extra development time, because testing is one of the best ways to prevent regressions long term and as the software changes and is touched by multiple developers.