docs: add polyrepo and monorepo ADR proposals

docs/proposals/ADR_Monorepo_Architecture.md

@@ -0,0 +1,30 @@
+# ADR: Monorepo Architecture
+
+## Status
+
+**Accepted** 
+
+## Context
+
+Considering the Distributed Embedded Systems project and related future work, we aim to decide between maintaining our project in a single repository or adopting a submodule-based approach (see [ADR:  Polyrepo Architecture using Git Submodules](ADR_Polyrepo_Architecture.md))
+
+A **monorepo** is a single repository that contains multiple distinct projects with well-defined relationships. 
+
+It is important to emphasize that a monorepo is not the same as a monolithic repository—this is a common misconception that often leads to confusion. Having all components of a project in the same repository does not imply maintaining a single artifact for deployment.
+
+## Proposal
+
+We propose adopting a monorepo architecture, complemented by a well-defined CI/CD pipeline to efficiently manage releases, deployments, and the integration of project components.
+
+## Consequences
+
+### Positive Consequences
+- **Unified access to code**: With a monorepo, all code is accessible for every component within the repository.  
+- **Simplified code-sharing**: Sharing code becomes easier, as all components are readily accessible.  
+- **Compatibility with Bazel**: The use of Bazel, which we are considering, is particularly effective in a monorepo setup.  
+- **Centralized configuration**: Configuration related to CI/CD, testing, and other aspects is centralized, ensuring consistency across the project.  
+
+### Negative Consequences
+- **Increased cloning time**: Monorepo projects can grow significantly in size, potentially leading to long wait times for git operations like cloning or checking the repository status.  
+- **Complex CI configuration requirements**: Poor CI/CD configuration can cause significant issues due to the interdependencies among project components.  
+- **Challenges with mixed technologies**: Supporting multiple technologies in the same repository can complicate the setup and require additional attention.  

docs/proposals/ADR_Polyrepo_Architecture.md

@@ -0,0 +1,32 @@
+
+# ADR: Polyrepo Architecture using Git Submodules
+
+## Status
+
+**Refused** 
+(Due to acceptance of [ADR: Monorepo Architecture](ADR_Monorepo_Architecture.md))
+
+## Context
+
+Considering the Distributed Embedded Systems project and related future work, we aim to decide between maintaining our project in a single repository or using submodules (see [ADR: Monorepo Architecture](ADR_Monorepo_Architecture.md))
+
+A **polyrepo architecture** is a software development approach where each project or component is stored in a separate repository, and their integration is managed through tools like Git submodules. This allows for greater modularity and flexibility when working with multiple independent projects.
+
+## Proposal
+
+Adopt a polyrepo architecture using Git submodules. Git submodules allow embedding one repository within another, enabling teams to manage dependencies between separate projects while maintaining clear boundaries.
+
+## Consequences
+
+### Positive Consequences:
+- **Improved modularity**: Each component can be developed, versioned, and deployed independently.  
+- **Fine-grained access control**: Different repositories allow distinct permissions and access levels for each project.  
+- **Smaller repository size**: Cloning individual repositories is faster and more efficient, especially for large projects.  
+- **Easier collaboration on specific modules**: Teams can focus on individual repositories without being affected by changes in unrelated parts of the system.  
+- **Clear separation of concerns**: Submodules help enforce boundaries between components, reducing potential cross-component interference.  
+
+### Negative Consequences:
+- **Complexity in managing submodules**: Submodules require careful management to avoid issues with synchronization, version mismatches, or broken dependencies.  
+- **Challenging updates**: Updating submodules involves extra steps, which can lead to errors if not handled correctly.  
+- **CI/CD setup complexity**: Configuring pipelines for multiple repositories and ensuring seamless integration can be more challenging compared to a monorepo.  
+- **Difficult cross-module changes**: Changes that span multiple modules require coordination across repositories, increasing the effort needed for implementation and testing.