From 1b71cde151f16d7b0d1a1f8f2c3af6a6d29ceb43 Mon Sep 17 00:00:00 2001 From: jem Date: Sat, 5 Jun 2021 14:47:15 +0200 Subject: [PATCH] extract the boundedContextSeparation principle --- adr-c4k/project-section.md | 24 +----------------------- principles/README.md | 2 +- principles/boundedContextSeparation.md | 26 ++++++++++++++++++++++++++ 3 files changed, 28 insertions(+), 24 deletions(-) create mode 100644 principles/boundedContextSeparation.md 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