Domain Type Creator

1. Use code generation: Create a JSON model and generate all artefacts using the appropriate profiles. See ORE Studio Codegen for details.
2. Update templates: If the domain type doesn't fit existing templates, modify the Mustache templates in library/templates/ to support the new pattern.
3. Manual creation: Only create artefacts manually as a last resort when code generation cannot support the required pattern.

1. Create a JSON model in projects/ores.codegen/models/{component}/

2. Generate all C++ artefacts:

   cd projects/ores.codegen
   # Generate all C++ facets (domain, repository, service, protocol, generator)
   ./run_generator.sh models/{component}/{entity}_schema.json output/ --profile all-cpp
   

3. Review the generated output in output/
4. Copy files to the appropriate projects/ores.{component}/ directories
5. Update CMakeLists.txt if needed (files picked up automatically via GLOB)
6. Build and verify
7. Raise PRs at designated checkpoints

1. Gather information about the domain type (name, fields, project location).
2. Follow the detailed instructions to create all required artefacts in order.
3. Build and test the new domain type.
4. Raise PRs at designated checkpoints and wait for review before proceeding.

After completing each phase:

1. Using cmake-runner skill, build and verify there are no errors.
2. Commit all changes with an appropriate message.
3. Push the branch and use pr-manager skill to raise a PR with the suggested title.
4. Wait for review feedback and address any comments.
5. Once approved, merge the PR back to main.
6. Use the feature-branch-manager skill to transition to the next phase.

Before starting, gather the following information from the user:

• Domain type name: the name of the new type (e.g., currency, account).
• Component location: which component the domain type belongs to (e.g., ores.refdata, ores.accounts).
• Fields: list of fields with their types and descriptions.

projects/ores.codegen/
├── run_generator.sh           # Main entry point
├── src/generator.py           # Generator implementation
├── library/templates/         # Mustache templates
└── models/                    # Model definitions
    └── dq/
        ├── dataset_bundle_domain_entity.json
        └── dataset_bundle_member_junction.json

1. Create a JSON model in projects/ores.codegen/models/{component}/
2. Run the generator to produce C++ files
3. Review the output in output/
4. Copy files to the appropriate projects/ores.{component}/ directories
5. Update CMakeLists.txt if needed (files picked up automatically via GLOB)
6. Build and verify

Example domain entity model with full C++ support:

{
  "domain_entity": {
    "component": "dq",
    "entity_singular": "dataset_bundle",
    "entity_plural": "dataset_bundles",
    "entity_title": "Dataset Bundle",
    "brief": "A named collection of datasets.",
    "description": "Detailed multi-line description...",

    "primary_key": {
      "column": "id",
      "type": "uuid",
      "cpp_type": "boost::uuids::uuid",
      "description": "UUID uniquely identifying this bundle."
    },

    "natural_keys": [
      {
        "column": "code",
        "type": "text",
        "cpp_type": "std::string",
        "description": "Unique code for stable referencing.",
        "generator_expr": "std::string(faker::word::noun()) + \"_bundle\""
      }
    ],

    "columns": [
      {
        "name": "description",
        "type": "text",
        "cpp_type": "std::string",
        "nullable": false,
        "description": "Detailed description of the bundle.",
        "generator_expr": "std::string(faker::lorem::sentence())"
      }
    ],

    "sql": {"tablename": "dq_dataset_bundles_tbl"},

    "repository": {
      "entity_singular_short": "bundle",
      "entity_plural_short": "bundles"
    },

    "cpp": {
      "includes": {
        "domain": ["<chrono>", "<string>", "<boost/uuid/uuid.hpp>"],
        "entity": ["<string>", "\"sqlgen/Timestamp.hpp\""]
      },
      "iterator_var": "b"
    }
  }
}

• Consistency across all domain types
• Reduces boilerplate errors
• Single source of truth for entity definitions
• Easy to update all instances when patterns change
• Supports both domain entity and junction table patterns

• Use snake_case for all C++ identifiers (classes, methods, variables)
• File names should match the class name exactly
• Headers use .hpp extension
• Implementation files use .cpp extension

• Group related functionality in logically named files
• Standard library includes first, then third-party, then project headers
• Use namespace aliases to reduce verbosity

• Add doxygen comments for all public APIs
• Explain the "why" in comments, not the "what"
• Include @brief tags for all documented items

When creating a service class to expose repository operations, follow these patterns: