add ddd-structure.md and one-layer-of-configuration.md

adr-provs/ddd-structure.md

@@ -0,0 +1,18 @@
+# ddd structure
+
+## Status
+
+Accepted
+
+## Context
+
+We wanted to have a consistent structure.
+
+## Decision
+
+* We preliminarily use the ddd structure: application / domain / infrastructure
+  * Reservation 1: find a better name for domain
+  * Reservation 2: decide what to put in domain / what to cover with unit tests
+  
+
+

adr-provs/one-layer-of-configuration.md

@@ -0,0 +1,19 @@
+# One layer of configuration
+
+## Status
+
+Accepted
+
+## Context
+
+In configuration management often convention code is mixed-up with installation and configuration code. 
+In order to enable reuse we discussed whether we want to separate convention from installation and configuration code.
+
+## Decision
+
+* To keep it simple, we follow the mixup strategy.
+  
+## Consequence
+
+* We use only one layer of configuration
+* We are the primary intended user

adr-provs/partial-execution.md

@@ -9,13 +9,15 @@ to be discussed
 We want to be able to execute single provision steps to apply partial installation / configuration.
 
 ### Options
-1. ClassAndFunction
+1. By CLI and specify ClassAndFunction
- - Abhängigkeiten
- - Transport von Credentials
 2. Switch on cli per parameter / mapping in code from parameter to function
 3. Per KotlinScript file
 4. Configurable in the configuration
 
+General points to keep in mind:
+- Dependencies
+- Transport of credentials
+
 ## Decision
 
 * Wir repräsentieren unsere Configuration
@@ -23,7 +25,6 @@ We want to be able to execute single provision steps to apply partial installati
 * Wir nutzen erst mal die Struktur von DDD application / domain / infrastructure - unter Vorbehalt
   * Vorbehalt1: besseren Namen für fachliches finden
   * Vorbehalt2: entscheiden, was in der domain testbar sein muss
-
+  
-* Wir nutzen nur einschichtige Konfiguration, da wir nur noch uns selbst als Nutzerkreis ansehen.