code review

src/main/jbake/content/documentation/arc42/adrs/ADR-001-PostgreSQL.adoc

@@ -38,7 +38,7 @@ We also do not expect that most of our databases will need to scale horizontally
 
 == Options we considered
 
-== MongoDB
+=== MongoDB
 MongoDB's main advantage of offering transparent sharding does not pay off for us, as we (see assumptions) do not need horizontal scaling.
 
 Storing arbitrary JSON documents is also not an advantage (compared to PostgreSQL), as
@@ -48,7 +48,7 @@ Storing arbitrary JSON documents is also not an advantage (compared to PostgreSQ
 
 We also have relatively limited expertise within the core team in using und operating MongoDB.
 
-== PostgreSQL
+=== PostgreSQL
 SQL databases remain the most widely used database systems (links) and PostgreSQL appears to be the most used open-source database system in professional settings (link).
 
 Every team member can use PostgreSQL since everyone is familiar with the concepts of relational databases.
@@ -57,7 +57,7 @@ Relational databases are highly mature and well-supported by common frameworks l
 
 Moreover, we have experience in operating PostgreSQL.
 
-== Cassandra
+=== Cassandra
 This is a similar case as with MongoDB, but in addition to its drawbacks, Cassandra's tooling support is expected to be the least mature among our three options.
 
 == Decision

src/main/jbake/content/documentation/arc42/adrs/ADR-002-Python.adoc

@@ -1,4 +1,4 @@
-= Python for all datascience related tasks
+= Python for all data science related tasks
 :jbake-type: page
 :jbake-status: published
 :jbake-date: 2023-11-23
@@ -8,6 +8,49 @@
 
 
 == The problem
-One of our top quality goals is that the recommendations we offer to our dancers should be good.
+
+One of our top quality goals is that the recommendations we are offering to our dancers should be good.
 So we want to use the best tooling and frameworks that help us in implementing a good recommender.
-Our main langugage ist Java. So at first, we could implement the recommender in Java.
+Our main langugage ist Java. So at first, we could implement the recommender in Java. We have the impression, that Java and its EcoSystem is not common when developing things like recommendation engines.
+
+=== Which quality goals are affected?
+
+Certainly, this is the QG2 (Good Recommendations).
+
+=== Which risks are affected?
+
+We have pretty limited experience in this data science stuff in general and with recommendation engine in particular.
+Choosing something that would require us to learn more, would put the project at risk, in that way, that we will be (at first) slower. Also the overall complexity of the system would increase if we are leaving the default programming language/tooling stack.
+
+=== Assumptions
+
+We are pretty sure, that there are two dominant languages out there with strong support for developing stuff like we need here for our recommendations.
+
+* Python
+* R
+
+Takling with Datascientists in our company, showed that R is especially being used for people with a Mathematics/Statistic Background while Pyhton is strong in for all with a more Engeneering Background.
+
+Also in Total we expect that Python is more prominent when looking at it holistically.
+
+We expect that we could leverage our (also not too deep) knowledge of Python to not loose more than about a developer month, with respect to the penalty only for learning something knew.
+
+
+== Options we considered
+
+=== Python
+Seems to be the goto language/EcoSystem when developing things like a recommendation system.
+Python is one of the most dominiant lanugages  in the world.
+Pyhton has the reputation to be easy to learn, which is also assesed by team members.
+=== Java
+
+Java, does not seem to be 
+
+=== R
+
+
+
+
+== Decision
+
+favor whats proven

src/main/jbake/content/documentation/arc42/src/05_building_block_view.adoc

@@ -38,13 +38,13 @@ Connect to the "Dancer" with our <<BBF>>.
 |<<BBF>> to Dancier. All calls from the internet are handled by this component. Additionally, it's also responsible for user/account/profile management. We started with a monolithic approach for Dancer, putting everything in one modular monolith. Having the mentioned functionalities included in Dancer gave us no issues so far, so we continue with this approach.
 
 |Interface
-|Dancer provides a link:https://editor.swagger.io/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fdancier%2Fdancer%2Fmaster%2Fswagger.yaml[REST API], giving our Angular Single Page Application (SPA) an entrypoint to communicate with the entire Dancier System.
+a|Dancer provides a link:https://editor.swagger.io/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fdancier%2Fdancer%2Fmaster%2Fswagger.yaml[REST API], giving our Angular Single Page Application (SPA) an entrypoint to communicate with the entire Dancier System.
 
 Refer to the link:https://project.dancier.net/documentation/arc42/index.html#whitebox_overall_system[whitebox overall system] to identify the services used by Dancer directly.
 
-Additionally, Dancer emits <<BusinessEvent>>s for every interesting use case it's primarily responsible for, particularly the handling of accounts and user profiles. These events are sent to an S3 Bucket and Kafka to be consumed by other services requiring this information.
+Additionally, Dancer emits <<BusinessEvent>>s for every interesting use case it's primarily responsible for. Particularly the handling of accounts and user profiles. These events are sent to an S3 Bucket and Kafka to be consumed by other services requiring this information.
 
-(The Dancer will forward also every event it receives via the REST Event Endpoing) it receives from the SPA, as it could not connect to Kafka.
+NOTE: As the SPA runs in the browser of our customer, they normally could not (directly) write Events to our Kafka Broker. For this reason, the dancer has a certain endpoint (see link:https://editor.swagger.io/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fdancier%2Fdancer%2Fmaster%2Fswagger.yaml[REST API]), to enable the SPA to publish events on our Kafka-Broker. Those will also be persisted in our S3-Bucket.
 
 |Risks/Smells
 |The Dancer is something in between a pure backend for frontend and a small modulith, as it also contains some modules with business logic. This hybrid design stems from the initial preference for a modulith over numerous microservices. The current setup may introduce some testing complexities, and if found too cumbersome over time, refactoring may be necessary.