This commit is contained in:
jem 2021-05-27 20:11:33 +02:00
parent 6b63baa503
commit af0e77c421
3 changed files with 77 additions and 0 deletions

View file

@ -0,0 +1,25 @@
# 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:
# Title
## Status
What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?

View file

@ -0,0 +1,25 @@
# How is the provs-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:
# Title
## Status
What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?

27
principles/README.md Normal file
View file

@ -0,0 +1,27 @@
1. Schnitt: Erst fachlich, dann technisch
2. Tests:
1. Jedes Element nur einmal testen
2. möglichst billig testen
3. YAGNI / KISS
#Postel's Law:
be conservative in what you do, be liberal in what you accept from others.
https://martinfowler.com/bliki/TolerantReader.html
5. DDD Aufteilung nutzen
1. Domain isoliert - isoliert testbar
2. Inputs / Outputs validieren
3. Aggregate bilden
6. Configuration ist dumm
7. Wir programmieren in Programmiersprachen und nicht in XML / Template / yaml ...
8. Gute Programmiersprachen erfinden ist schwierig, drum lassen wir das
9. Microkernel
10. Schnelles Feedback ist relevant
11. Wenn wir Magie wirken, dann muss die gut sein
12. Wir vermeiden zirkuläre Abhängigkeiten
13. Modularisierung ermöglichen
14. Komposition
15. versionierte / nicht veränderbare Dependency
16. Das nötigste ist dokumentiert