diff --git a/adr-c4k/project-section.md b/adr-c4k/project-section.md
index d7ef29c..b9c054a 100644
--- a/adr-c4k/project-section.md
+++ b/adr-c4k/project-section.md
@@ -6,29 +6,7 @@ accepted
 
 ## Context
 
-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
+We need some place to collect common used code for our Convention4Kubernetes modules. We follow the [Bounded-Context-Separatoin rinciple](../principles/boundedContextSeparation.md).
 
 ## Decision
 
diff --git a/principles/README.md b/principles/README.md
index e1f628f..8df92d8 100644
--- a/principles/README.md
+++ b/principles/README.md
@@ -1,4 +1,4 @@
-1. Schnitt: Erst fachlich, dann technisch
+
 2. Tests: 
   1. Jedes Element nur einmal testen
   2. möglichst billig testen
diff --git a/principles/boundedContextSeparation.md b/principles/boundedContextSeparation.md
new file mode 100644
index 0000000..850d97a
--- /dev/null
+++ b/principles/boundedContextSeparation.md
@@ -0,0 +1,26 @@
+# Bounded Context Separation Priciple
+
+For mudole section there are several tactiques. One important is the section alongside of Bounded Contexts (Martin Fowlder: Bounded Context)[https://martinfowler.com/bliki/BoundedContext.html].
+
+But separation of modules always has it's up and downs:
+
+* 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