c4k section decission

adr-c4k/project-section-artifact.puml

@@ -0,0 +1,25 @@
+@startuml
+artifact common [
+<b>c4k-common
+---
+contains commonly used stuff for Convention4Kubernetes modules.
+===
+
+predicates, config handling with aero, gopass resolution, yaml serialization and encoding.
+]
+
+artifact mbot [
+<b>c4k-mastodon-bot
+---
+Module generating k8s deployments for mastodon-bot.
+]
+mbot -> common
+
+artifact kc [
+<b>c4k-keycloak
+---
+Module generating k8s deployments for keycloak.
+]
+kc -> common
+@enduml
+

adr-c4k/project-section.md

@@ -1,23 +1,45 @@
 # How is the c4k-project section?
 
-
-This is the template in [Documenting architecture decisions - Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
-You can use [adr-tools](https://github.com/npryce/adr-tools) for managing the ADR files.
-
-In each ADR file, write these sections:
-
 ## Status
 
-What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
+accepted
 
 ## Context
 
-What is the issue that we're seeing that is motivating this decision or change?
+We need some place to collect common used code for our Convention4Kubernetes modules.
+
+Discussion about project-section in general
+* Value
+    * Smaller modules make it easier to cope with systems complexity
+        * test code seperately
+        * fewer people work on the same repo -> less merging
+    * Increase consistency by reusing code instead of creating redundancy
+    * enforces clearer architectur (decisions)
+    * separation of code along the different development velocities border.
+    * enforces architectural section
+* Cost
+    * increase of systems complexity
+        * Dependency Hell / transitive dependencies
+        * Section requires good documentation
+        * more artifacts
+    * Worse Developer Experience
+        * Refactoring across multiple modules is hard to handle
+        * Debugging of seperate modules my be time-consuming (multiple layers)
+        * some coding tools (e.g. jump to definition) do not work over multiple repositories
+        * slower development roundtrip (e.g. when using repl)
+    * less awarness of what co-workes are commiting/working on
+    * Danger of naive projcet section
 
 ## Decision
 
-What is the change that we're proposing and/or doing?
+[](project-section-artifact.png)
+
+1. We move common used code (predicates for spec, config handling with aero, gopass resolution, yaml serialization and encoding) to c4k-common project.
+2. For cli & web frontend code we accept redundancy till we've a clearer picture on how to extract commons
+3. For postgres deployments we accept redundancy till we've a clearer picture on how to extract commons
 
 ## Consequences
 
-What becomes easier or more difficult to do because of this change?
+1. We can use described code in common.
+2. After more experience we will decide about a changed section.
+