EA-ENTERPRISE-FOUNDATION-PRINCIPLE-CATALOG

Katalog der Enterprise-Grundprinzipien#

Zweck#

Dieser Katalog bewahrt die universellen Architekturregeln der historischen PRI-001 – Architecture Principles nahezu wortgleich und ordnet sie in die aktuelle Enterprise-Ontologie ein. Er ist die kanonische Heimat dieser Foundation-Regeln; spezialisierte Prinzipiendokumente erläutern einzelne Regeln und bilden keine konkurrierende Sammlung.

⌘MeaningBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen., ⌘ArtifactEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. und ⌘RelationshipEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext. bleiben gleichrangige fundamentale Familien. Wenn eine historische Formulierung „Artifact“ verwendet, gilt sie für konkret identifizierbare und behandelbare Elemente und reduziert Meaning oder Relationship nicht auf Artifact-Unterarten.

P-000 – Artifact First#

Fachlich relevante Einheiten werden als Artifacts mit stabiler Identity, Type, Status, Version, Verantwortung und Relationships geführt.

P-000a – Eine fachliche Wahrheit#

Jede fachliche Aussage besitzt genau eine führende Quelle. Andere Dokumente referenzieren diese Quelle, statt dieselbe Aussage parallel zu pflegen.

Die Repositoryverantwortung wird durch das ◆Cross-Repository Responsibility ModelKanonische organisationsweite Zuordnung von Wissen, Realisierung, Werkzeugen und Runtime-Zustand zu den verantwortlichen Repositories. bestimmt.

P-000b – Vollständige Architekturentscheidungen#

Wesentliche Architekturentscheidungen werden so dokumentiert, dass sie auch später ohne Chatverläufe verständlich bleiben. Dazu gehören mindestens Entscheidung, Motivation, Beispiele, Konsequenzen und Hinweise zur Erweiterbarkeit.

P-001 – Artefaktorientierung#

Alles konkret identifizierbare und behandelbare Modellierbare ist ein Artifact. Dokumente, ⌘QuellcodeCode ist eine ausführbare oder interpretierbare technische Realisierung, die durch Tests und Runtime-Evidence überprüfbar bleibt., Modelle, APIs, Tests, Build-Dateien und Distributionen sind unterschiedliche Materialisierungen oder Projektionen von Artifacts und keine voneinander getrennten Grundobjekte.

Die vollständige Abgrenzung zu Meaning und Relationship steht im ◆Enterprise Ontology CoreDefiniert Meaning, Artifact und Relationship als fundamentale semantische Familien sowie Identity als universelle Eigenschaft..

P-001a – Universumsweite Identity#

Jedes fachlich eigenständige Element besitzt im gesamten betrachteten Enterprise- und Solution-Kontext genau eine stabile Identity. Repositorys, Building Blocks, Architecture Repositories, Dateipfade und Distribution Provider bilden keine getrennten fachlichen Identity-Namespaces.

Identifierformat, Registry, Persistenz und technische Konfliktauflösung werden von der jeweiligen Solution realisiert.

P-002 – Relationships sind erste Bürger#

Relationships sind nicht nur Linien in einer Darstellung. Sie sind fachliche Elemente mit Type, Richtung, Status, Beschreibung, Historie und optionalen Eigenschaften.

Der Detailvertrag steht im ◆Typed Relationship PrincipleFachliche Zusammenhänge werden als typisierte semantische Relationships modelliert..

P-012 – Historisierung#

Fachliche Änderungen sind historisierbar. Frühere Zustände sollen nachvollziehbar bleiben. Die konkrete Revisions- und Speichertechnik gehört in die jeweilige Solution.

P-014 – Stabile IDs#

Fachliche Elemente erhalten stabile IDs, die nicht wiederverwendet werden. Eine ID ist die technische Repräsentation einer fachlichen Identity und nicht deren Ersatz.

P-017 – Dokumentation ist Teil des Produkts#

Architektur, Decisions, Features und Tests sind keine Nebendokumente. Sie sind Artifacts oder kontrollierte Materialisierungen solcher Artifacts.

P-018 – Betrieb ist Teil der Architektur#

Deployment, Monitoring, Backup, Health Checks und Fehlerbehandlung werden von Anfang an mitgedacht. Materialisierung allein belegt keinen Erfolg; Verification und ⌘EvidenceTechnical documentation artifact. folgen dem ◆Engineering Materialization Verification PrincipleTechnical documentation artifact..

P-021 – Gemeinsames semantisches Modell#

Meanings, Artifacts und Relationships bilden gemeinsam das semantische Modell der betrachteten Realität. Projektionen, Materialisierungen und Publikationen besitzen keine unabhängige fachliche Wahrheit.

P-022 – Questions before Views#

Jede Sicht, Analyse oder Dokumentation beantwortet mindestens eine fachliche Fragestellung. Frameworks und Ausgabeformate begründen keine eigene fachliche Struktur.

P-023 – Reasoning before Rendering#

Fachliche Auswahl, Berechnung, Interpretation und Ableitung erfolgen vor dem ⌘RendererEin Renderer erzeugt eine konkrete technische Ausgabeform aus einer vorbereiteten Dokumentationsprojektion. Beispiele sind HTML, PDF, Markdown, JSON oder ein Suchindex.. Renderer präsentieren bereits aufbereitete Antworten und bleiben semantikfrei.

P-024 – Improvement before Expansion#

Erkenntnisse werden vorrangig durch Präzisierung, Ergänzung oder Korrektur bestehender Meanings, Artifacts und Relationships zurückgeführt. Neue Elemente entstehen nur bei neuer fachlicher Identity.

Das ◆Semantic Preservation PrincipleArchitekturwissen wird konsolidiert und nicht stillschweigend gelöscht oder umgedeutet. regelt ⌘ProvenanceProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung. und den Umgang mit Widersprüchen.

P-025 – Theory before Function#

Neue größere Funktionen werden vor Architecture- und Building-Block- Entscheidungen gegen die führende Domain Theory und mindestens ein geeignetes Validation Scenario geprüft. Die jeweilige Solution bestimmt die konkreten Theorie- und Szenarioartefakte.

Migrationsprovenienz#

Nahezu 1:1 konsolidiert aus:

• SolutionArchitecture:20-principles/PRI-001-Architecture-Principles.md, Version 0.3;
• SolutionArchitecture:00-overview/architecture-contract/02-Constitution.md, Version 001.

Vollständiges Regelinventar und Abweichungsbegründungen:

• solution-architecture:99-reports/SE-0014-architekturregeln-regelinventar-und-uebernahmematrix.md

Related Architecture#

• Architecture Contract – governed-by
• Enterprise Ontology Core – derived-from
• Cross-Repository Responsibility Model – governed-by
• ◆Architecture Derivation PrincipleNiedrigere Ebenen spezialisieren und materialisieren höhere Ebenen, ohne sie neu zu definieren. – related-to
• Semantic Preservation Principle – related-to
• Typed Relationship Principle – related-to