Blueprints
Blueprints are structured starting points for teams that want fast setup without sacrificing architecture clarity. Instead of building every entity, attribute, and relation from scratch, you start with a proven domain template and customize it to match your specific needs.
What a Blueprint Provides
A blueprint is a complete, pre-built Mockomat project that includes:
- Coherent base entities — a set of domain tables that work together as a logical unit (e.g.,
Product,Category,Reviewfor an e-commerce domain). - Initial relation strategy — relations between entities are already defined with correct cardinality and direction.
- Attribute configuration — each entity comes with meaningful attributes, types, and flags (sortable, filterable, searchable) already set.
- Data mappings — fields are pre-mapped to appropriate data sources (real datasets, Faker, constants) so the blueprint works immediately in preview.
- Starter operation expectations — API query names and operation exposure are configured for typical use cases.
- Meaningful defaults — pagination, sorting, and filtering are configured so preview behavior is useful out of the box.
The result is a project you can clone and query within seconds — then customize at your own pace.
Blueprint gallery with category and complexity overview.
Available Blueprint Categories
Blueprints cover common domain patterns that teams encounter frequently:
| Category | Example Entities | Typical Use Case |
|---|---|---|
| E-Commerce | Product, Category, Order, Customer, Review | Online shops, marketplaces, product catalogs |
| Blog / CMS | Post, Author, Category, Comment, Tag | Content platforms, editorial workflows |
| CRM | Contact, Company, Deal, Activity, Pipeline | Sales teams, customer relationship tracking |
| Project Management | Project, Task, Team, Member, Sprint | Agile workflows, task tracking systems |
| SaaS / Subscription | Subscription, Plan, Invoice, Customer, Payment | SaaS billing, subscription management |
| Inventory | Product, Warehouse, StockLevel, Supplier, Transfer | Warehouse management, supply chain |
| HR / People | Employee, Department, Position, TimeEntry, Leave | HR systems, workforce management |
Each blueprint is designed by experienced architects and reviewed for structural quality. The entities, relations, and naming conventions follow domain-driven design principles.
Blueprint category cards with entity count and complexity indicator.
How to Use a Blueprint Effectively
1. Browse and Select
Open the blueprint gallery and browse by category. Each blueprint card shows:
- The domain category
- Number of entities included
- A brief description of the covered use case
- Complexity indicator (simple, moderate, comprehensive)
Select the blueprint that most closely matches your target domain. It does not need to be a perfect match — you will customize it in the next steps.
2. Clone into Your Workspace
Click the clone button to create a copy of the blueprint in your workspace. This creates a new project with all the blueprint's entities, attributes, relations, and mappings. The original blueprint is not modified.
What gets cloned:
- All tables and their attributes
- All relation definitions
- All data mappings (OFF_FIELD, FAKE, CONST)
- API configuration (query names, operation exposure)
- Pagination and sorting defaults
What does not get cloned:
- The original blueprint name (you choose a new project name)
- Any blueprint-specific metadata or badges
- Import job history
3. Rename with Your Business Language
Replace the blueprint's generic names with your team's actual terminology. If the blueprint uses Product but your domain calls it Listing or Item, rename it now. Consistent naming from the start prevents confusion later.
4. Review Attributes Table by Table
Walk through each entity and check:
- Are all the attributes relevant to your domain?
- Do you need additional attributes not in the blueprint?
- Are the types correct (string, number, boolean, date)?
- Are the right fields marked sortable, filterable, and searchable?
Remove attributes you do not need and add any that are missing. The blueprint gives you the structure — you provide the domain specifics.
5. Validate Through Preview
Run a preview query to confirm the cloned and customized model works correctly. Check that:
- Data mappings produce realistic values
- Relations resolve as expected
- Filters and sorts work on the fields you configured
- The overall response shape matches your frontend expectations
Blueprint clone flow into active workspace.
Customization Strategy
Do not rewrite everything at once. Keep the blueprint skeleton and evolve in focused passes. This approach preserves structural integrity while allowing progressive refinement.
Pass 1: Naming and Core Attributes
Focus only on renaming and adjusting the most important attributes:
- Rename entities to match your business language
- Rename key attributes (identifiers, display names, primary values)
- Add 1-2 critical attributes per entity that the blueprint does not include
- Remove attributes that are clearly irrelevant
Do not adjust relations, API config, or mappings in this pass.
Pass 2: Relation Cleanup
With names stabilized, review and adjust relations:
- Verify cardinality is correct for your domain (1:1, 1:n, m:n)
- Adjust direction if the blueprint's ownership model does not match yours
- Add relations the blueprint does not include
- Remove relations that do not apply
Run preview after this pass to confirm nested queries still resolve correctly.
Pass 3: API Exposure Alignment
Configure which operations are available and how they are named:
- Rename queries to match your API conventions
- Enable or disable list/detail operations per entity
- Adjust pagination defaults
- Set appropriate filter and sort configurations
Pass 4: Runtime Validation
Final validation pass:
- Run comprehensive queries against every entity
- Test all filters and sorts
- Verify relation traversal at every level
- Address any remaining hints or warnings
After this pass, your customized blueprint should be production-ready for mock API consumption.
Blueprint customization in model and API views.
Blueprint Quality Criteria
Every blueprint in the gallery meets minimum quality standards:
- At least 2 entities with meaningful names and descriptions
- At least 1 relation connecting entities
- Complete attribute mappings — no unmapped fields
- Proper naming conventions — PascalCase entities, camelCase attributes
- No placeholder or random names — all names reflect real domain concepts
- Working preview — the blueprint produces valid query results out of the box
These criteria ensure that every blueprint is immediately useful, not just a skeleton.
Official and Community Blueprints
Blueprints come in two categories:
Official Blueprints
Created and maintained by the Mockomat team. These are:
- Reviewed for structural quality and naming conventions
- Updated with new features and best practices
- Marked with an "Official" badge in the gallery
- Guaranteed to work with the current platform version
Community Blueprints (Coming Soon)
Published by registered users and shared with the community. Community blueprints:
- Go through an automated quality review (naming, structure, completeness)
- Are moderated by the Mockomat team
- Show the author's name and clone count
- Can be promoted to official status if quality is exceptional
Community blueprint submission and review flow.