Das Metamodell der Bausteine einer Produktdokumentation richtet sich an jene Personen, die ein abstraktes Modell für das Verständnis der Zusammenhänge brauchen. Das Metamodell soll eine Orientierung für den Einsatz von cards+ und der effektiven Verwendung der Bausteine im Wiki sein.
Die Bausteine orientieren sich an Konzepten, die Eric Evans in seinem Buch «Domain-Driven Design: Tackling Complexity in the Heart of Software» sehr ausführlich beschreibt. Das gilt im Besonderen für die gemeinsame Sprache (engl. ubiquitous language) und der Festlegung von Kontextgrenzen (engl. bounded context). Die gemeinsame Sprache findet bei cards+ Ausdruck durch den Baustein Term im Glossar und die konsequente Verwendung der Bausteinstruktur im Wiki entsprechend dem Prinzip COD. Kontextgrenzen werden in den Bausteinen Domain (Gruppierung eng verwandter Dienste und Objekte) und Service (z.B. für die Gruppierung der Microservices eines Dienstes) definiert.
In den Bausteinen der Systembeschreibung werden die Grenzen des IT-Systems definiert und alle Fähigkeiten der Software vollständig, widerspruchsfrei und hierarchisch erfasst. Fähigkeit ist der Sammelbegriff für Anwendungsfälle, besonderen Situationen und bekannten und akzeptierten Fehler eines IT-Systems.
Die Bausteine sind streng hierarchisch strukturiert und unterstützen so die Arbeitsweise top down bei der Analyse. Das bedeutet, dass ein Autor die Grenzen der Software im Baustein Topic beschreibt. In seiner weiteren Analyse der Fähigkeiten der Software gibt er im Baustein Epic einen Überblick. Den Baustein Case nutzt er, um jede einzelne Fähigkeit der Software zu erfassen und mit den Essenzschritten in der Lösung den Übergang zu den Bausteinen der Systemstruktur zu schaffen.
Die Bausteine der Systemstruktur haben das Ziel, die Struktur der Software korrekt zu erfassen und einen Überblick über das Zusammenspiel der Dienste und Objekte zu geben. Ein nachrichten-orientierter Architekturstil ergibt eine andere Systemstruktur als die Realisierung eines IT-Systems mit einem monolithischen Applikationsservers.
Die Bausteine sind Platzhalter für Elemente (engl. building blocks) der Software. Abhängig vom Architekturstil ergeben sich durch den Baustein Domain Gruppen von Diensten (Baustein Service) und Objekten (Bausteine Event bzw. Entity). Der Baustein Task steht für Handlungsanweisung, die eine Betriebsorganisation braucht, um einen unterbrechungslosen und störungsfreien Betrieb des IT-Systems zu gewährleisten.
In den Bausteinen für den Architekturentwurf werden die vom Auftraggeber geforderten Qualitätsmerkmale, fundamentale Entscheidungen und übergreifende Konzepte nachvollziehbar erfasst. Ein ganz wichtiges Ziel ist die Darstellung und Kommunikation des Architekturstils.
Die Bausteine für den Architekturentwurf schaffen einen Rahmen für fundamentale Entscheidungen, Konzepte und Richtlinien. Die Bausteine Decision und Concept haben die Aufgabe, den Architekturstil nachvollziehbar zu beschreiben. Das ist ein wichtiges Element der Kommunikation im Team und mit allen interessierten Parteien. Mit dem Baustein Module werden eingesetze fremde Produkte erfasst. Mit dem Baustein Policy bekommen Richtlinien einen festen Platz in der Produktdokumentation.