Architecture
Last updated
Last updated
Architecture should be designed for change, and you must never make comproises that impact architecture goals negatively as architecture is by definition hard to change .
An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensions
Source:
API First, REST/Event Driven, SaaS, Cloud, and Microservices. We’re creating APIs first before we code them, using the REST/Event Driven architectural style to ensure we’re able to scale as our department and business grows in scope, evolving our systems in parallel. Building for SaaS makes our applications ready to live on the Internet, where embracing the cloud ensures that as a modern architecture, we’re fostering innovation. Finally, our adoption of Microservices ties all these principles together in a powerful architectural style that lets us move fast while we keep our complexity low. Source:
API First - as a plattform you care more about APIs/ business functions then the UI as the UI could be delivered by someone else using your API.
Testing for "First Principles" (basis that will be hard to correct in the long term and the negative impacts in production can only be monitored later when they stack up) -> can be de priortized for first mvp?:
Code Quality
Complexity
Functionality (easier to test and interpret where the error is on unit level but in the end only relevant on the quality level of the solution)
Testing "Quality" (how good is the current solution:
Real time monitoring for (
perfomormance
security
Automation ( -> AI)
Reasonable Security
Limited Blast Radius
solution (process & component)
implementation / technology (frameworks)
production
evolution
Tool:
Architectural decision should be documented in a . My private decision are located here in based on this .
Use the and
