c4k section decission

This commit is contained in:
jem 2021-05-31 20:39:25 +02:00
parent 0fee2119a1
commit 6de8bd841d
3 changed files with 57 additions and 10 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

View file

@ -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

View file

@ -1,23 +1,45 @@
# How is the c4k-project section? # 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 ## Status
What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.? accepted
## Context ## 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 ## 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 ## 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.