Enterprise Data Modeling with FileMaker
ExpertApply entity-relationship theory, domain-driven design, and bounded contexts to FileMaker solutions serving hundreds of users and millions of records.
What you'll learn
- How to apply bounded contexts to FileMaker table organization
- How to model aggregates and entities in FM
- How to design the graph for team ownership of sub-domains
- How to use events/audit tables to decouple business processes
Enterprise data modeling in FileMaker goes beyond normal forms. It requires domain analysis -- understanding which data belongs together, which contexts own which records, and how to design boundaries that prevent accidental coupling. Domain-driven design (DDD) concepts translate surprisingly well to FileMaker's table occurrence groups and relationship graph, giving teams a shared vocabulary for architecture decisions.
Bounded contexts in FileMaker
A bounded context is a self-contained sub-domain with its own data model and vocabulary. In FM, each bounded context maps to a table family sector in the relationship graph. Cross-context dependencies go through explicit integration points (shared IDs, event tables).
// Bounded context map for a field service solution: // Context 1: CRM (Contacts, Accounts, Opportunities) // Context 2: Work Orders (WorkOrders, Tasks, Assets, Technicians) // Context 3: Billing (Invoices, Payments, Contracts) // Context 4: Inventory (Parts, Locations, Movements) // Cross-context links are explicit: // WorkOrders::AccountID -> CRM Accounts (read-only reference) // Invoices::WorkOrderID -> Work Orders (trigger for billing) // Each context team owns their tables; changes to CRM do not break Work Orders
Sign in to track your progress and pick up where you left off.
Sign in to FM Dojo