- Classes & Objects
- Domain Experts
- Architects
- Database Schemata
- Long-term stable structure
- Form
- Roles, identifiers, activation records
- End Users
- User Experience people
- Interface designers
- Ever-changing functionality
- Function
- Dokumentiert und bekannt.
- Es beschreibt den Unterschied zwischen dem aktuellen Zustand und dem benötigten.
- Das Lösen des Problems muss messbar sein.
- Kurze, klare Problembeschreibung in natürlicher Sprache.
- Die Definition muss konsistent sein.
Zu beachten
- Wem "gehört" das Problem?
- Feature-Creeping
- Achtung vor Lösungen in der Verkleidung von Problemen...
- S Specific
- M Measurable
- A Attainable
- R Relevant
- T Time-bound
- I Independent
- N Negotiable
- V Valuable
- E Estimable
- S Sized appropriately/Small
- T Testable
- Die Fünf Ws Es wird so lange nachgefragt, bis die Ursache eines Problems klar ist.
- Ishikawa Diagramm Ursache-Wirkungs-Diagramm um die Kausalitätsbeziehungen darzustellen.
- Architektur ist mehr Form als Struktur
- Architektur ist mehr Verdichtung als Abstraktion
- Architektur hat statische und dynamische Komponenten
- Architektur geht jeden (Entwickler) was an
- Ein Großteil der Architektur dient nicht dazu, Anwender-Probleme zu lösen
- Architektur muss nicht schwer sein
Technik 1 Auf die Form ("Was das System ist") konzentrieren ohne übermässig auf die Funktionalität ("Was das System macht") zu achten.
Technik 2 Aufteilen der Komponenten nach Wahrscheinlichkeit der Änderung.
Die Struktur einer Software spiegelt die Struktur einer Organisation wieder.
Technik 3 Aufteilen der Form, so dass jeder Teil so unabhängig wie möglich ist.
Technik 4 Eigenständigkeit der Teams durch die Bestimmung, wo Änderung zusammenfallen.
Einzelne Komponenten/Subsysteme, die ein klar definiertes Gebiet verantworten, sollten
- einen hohen Zusammenhang haben.
- so weit wie möglich von Nachbarsystemen entkoppelt sein.
Eine agile Herangehensweise sollte sich grob nach diesen Regeln richten
- Design-Paradigmen unterstützen die Unabhängikeiten des Teams und spiegeln die Anwender-Domäne wieder.
- Es können in einem komplexen System mehrere Paradigmen autauchen.
- Das Paradigma ordnet sich der Aufteilung unter.
- Die Paradigmen sind entsprechend
Technik 5 Das Aufteilen sollten primär menschliche Überlegungen bestimmen, erst danach Software-Engineering.
Domänen sind die wichtigsten Dinge eines Systems.
Technik 6 Domänen sollten vorsichtig aufgeteilt werden; Domänen nicht geographisch oder über Architekturartefakte aufteilen.
Technik 7 Auf die Möglichkeit einer Produktlinie achten und diese zur Unterstützung für Aufteilungen benutzen.