Target filename for the Prisma schema file containing this component's tables.
🔧 TECHNICAL FIELD #2: Determined AFTER reasoning and namespace are
complete. Follows the naming convention schema-{number}-{domain}.prisma
where the number indicates dependency order and domain represents the
business area.
Business domain namespace that groups related models.
🔧 TECHNICAL FIELD #1: Determined AFTER reasoning is complete. Used in Prisma documentation comments as "@\namespace directive". Examples: "Systematic", "Actors", "Sales", "Carts", "Orders", "Coupons", "Coins", "Inquiries", "Favorites", "Articles"
Final rationale for this component's composition.
⭐ REASONING FIELD #3: The conclusive reasoning that cements the component's structure before committing to technical choices (namespace, filename).
Example:
"This component groups all actor-related tables to maintain a clear
separation between identity management and business transactions."
Review considerations for this component grouping.
⭐ REASONING FIELD #2: After initial thinking, the AI reviews its decisions by considering relationships with other domains and validating the grouping strategy.
Example:
"Reviewed relationships with other domains. While customers create orders,
the customer entity itself is fundamentally about user identity, not sales."
Array of table designs that will be included in this component's schema file.
Contains all database tables that belong to this business domain, each with a name and description explaining its purpose. This ensures logical grouping, proper organization, and clear documentation of related data structures.
Initial thoughts on why these tables belong together.
⭐ REASONING FIELD #1: This field comes FIRST to ensure the AI reasons through the component's purpose before determining technical details. Function calling order matters - thinking drives decision-making.
Example:
"These tables all relate to user management and authentication.
They share common patterns like user identification and access control."
Interface representing a logical grouping of database tables organized by business domain for schema file generation.
Components provide a systematic way to organize database tables into coherent groups following domain-driven design principles. Each component represents a specific business domain or functional area that will be generated as a separate Prisma schema file, ensuring maintainable and logically structured database architecture.
This interface is primarily used during the database design phase when the Database agent analyzes requirements and determines the complete scope of tables needed, then organizes them into logical groups based on business relationships and functional dependencies.
Usage in Schema Generation Process
Components serve as the blueprint for generating multiple Prisma schema files:
Domain Organization Examples
Based on typical business applications, components commonly include:
Relationship to AutoBeDatabase.IFile
Each AutoBeDatabaseComponent serves as a blueprint for generating one IFile during the schema generation process. The component's metadata (filename, namespace, tables) is used to structure the actual Prisma schema file with proper models, relationships, and indexes.
Author
Samchon
See