architecture principles

src/main/jbake/content/architecture-decision-principles.adoc

@@ -27,63 +27,34 @@ So we want to provide our members with principles that guide them through a smoo
 |===
 |Id|Name|Description
 
-|G1
-|Embrace Uncertainty
-|Uncertainty is not a problem to be solved,
-but an opportunity to uncover options in the face of the unknown.
-Rather than seeking false precision through exhaustive upfront analysis,
-this principle encourages a Start Less, Finish More mindset while still demanding a clear vision to follow.
-It emphasizes documenting assumptions, creating minimal viable strategies
-and iteratively adapting plans based on evolving insights.
-
-|G2
+|AP1
 |Delay Design Decisions
 |Delay design decisions until they are necessary.
 Decisions should be made at the last responsible moment, fostering a culture of experimentation.
 This will gather new insights that can be used to iteratively design the architecture.
-There is no point in designing and implementing capabilities upfront that may never be used
+No point in designing and implementing capabilities upfront may never be used
 - it is a waste of time and resources.
 
-|G3
-|Design for Change
-|The architecture should be designed to support change, not to prevent it.
-This means that the architecture should be loosely coupled, modular, and extensible.
-It should be easy to add new capabilities and to change existing ones.
-The architecture should be designed to support the ability to experiment and learn.
-
-|G4
+|AP2
 |Principle of Least Surprise
 |Build software and design the architecture such that it doesn't surprise users or fellow developers.
 When making decisions, prioritize predictability and ease of use over cleverness and novelty.
 This general principle can be applied to many aspects,
 such as making architectural decisions as well as building a clear UI for the end user.
 
-|G5
+|AP3
 |Low Coupling, High Cohesion
 |Strive for low coupling, where modules minimize dependencies on each other,
 ensuring changes in one module have minimal impact on others.
 Simultaneously, pursue high cohesion within modules,
 ensuring closely related code elements work together seamlessly,
 fostering maintainability, readability and efficient development.
 
-|G6
-|Cohesive Code Structuring
-|Build a cohesive structure for code not only based on technical distinctions
-but primarily on the business domain or features they serve.
-Files that are used for providing the same features should be relatively close by,
-sharing the same parent directory / module where possible.
-This approach enhances code cohesion, allowing developers working on a particular feature
-to locate and modify related files efficiently.
-
-|G7
-|Compliance with Law
-|Compliance with all relevant laws and regulations.
-
-|G8
-|Non-proliferation of Technology
+|AP4
+|Go deep not wide
 |Technical diversity will be controlled to reduce complexity.
 
-|G9
+|AP5
 |Keep it simple stupid (KISS)
 a|Based on our interpretation of
 https://en.wikipedia.org/wiki/Agile_software_development[Agile Development]
@@ -102,13 +73,7 @@ As well as it applies to "bigger" things eg.
      * Deciding architectural things like using CQRS
      * Using microservices vs. putting things into a monolith
 
-|G10
-|Shared Resources
-|Solutions will seek to maximum sharing of
-resources such as network, computing, storage
-and data.
-
-|G12
+|AP6
 |Favor what is proven
 a|     Default for standard options. Eg. when there are several similar web frameworks, go for the more prominent one. Because we expect that:
 
@@ -117,21 +82,9 @@ a|     Default for standard options. Eg. when there are several similar web fram
       * have better tooling support (if applicable)
       * have it easier to find more developers
 
-|G13
+|AP7
 | Match techniques with skills of core team members
 | The chosen technique should be either already known by the team (or part of the team) or the team must be willing to learn it.
 
-|SA1
-|Separation of Concerns
-|It will be possible to change a component with
-minimal impact on other components.
-
-|SA2
-|Loosely Coupled Services
-|Services will be loosely coupled (producers loosely coupled with consumers).
-
-|SA3
-|Service Abstraction
-|Services will hide their underlying implementation details.
 |===