You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the trainings attendees are very often surprised that their decisions e.g. for/against splitting a domain, picking a technology, making something a macro or micro architecture decision is supposed to be justified by referring to which Quality Goal (or scenario) this decision aims to fulfill. Thus we should explicitly request to stress this in certain parts of the curriculum
The text was updated successfully, but these errors were encountered:
I like the idea. Maybe we can look at "architecture principles" as well. Those are driven by strategic business goals and risks. They are therefore related to the elevator mentioned in #20. Especially if you have many teams, it is hard to communicate the main business drives in a good manner so that architectural requirements and decisions can derived from them.
Having those, it is always possible to trace a local (or global) architecture decision to a requirement and then to a business goal. You can vice versa show how a business goal or risk is addressed.
In the trainings attendees are very often surprised that their decisions e.g. for/against splitting a domain, picking a technology, making something a macro or micro architecture decision is supposed to be justified by referring to which Quality Goal (or scenario) this decision aims to fulfill. Thus we should explicitly request to stress this in certain parts of the curriculum
The text was updated successfully, but these errors were encountered: