TocoAI Collaborative Workflow

Overall Process Overview

┌─────────────────────────────────────────────────────────────┐
│                       Project Kickoff                        │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│           Phase 1: Architect-Led System Modeling             │
│      (Sequential, must be completed before Phase 2)          │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│         Phase 2: Parallel Module Development                 │
│    (Parallel, each person owns one module independently)     │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│               Phase 3: Integration & Release                 │
└─────────────────────────────────────────────────────────────┘

Phase 1: Architect-Led System Modeling

👤 Owner: Architect　⏱️ Mode: Sequential, all members participate in Review　✅ Done When: All module boundaries are clear, ER design review passed, cross-module dependencies confirmed

Step 1｜Requirements Analysis & Domain Discovery

Input: Product requirements documents, PRD, prototype diagrams

Architect tasks:

• Align core business processes with product and business stakeholders
• Identify core domain, supporting domain, and generic domain
• Preliminarily define domain boundaries and determine which business modules the system involves

AI assistance:

• Provide PRD or prototype diagrams to AI, let DomainArchitect help identify domain objects and module boundaries
• Typical prompt: “Based on the following requirements document, help me identify the core domains and suggest module divisions for the system”

Deliverables:

• Domain division draft
• Core business process description

Step 2｜Module Division & Boundary Confirmation

Architect tasks:

• Define the responsibility boundary of each Module, following high cohesion and low coupling principles
• Determine the public RPC interface list across modules (which services need to be exposed externally)
• Assign a responsible developer for each module

AI assistance:

• Use DomainArchitect to create module structures in Toco
• Typical prompt: “Create the following modules: member, order, room, payment, and annotate the responsibilities of each module”

Deliverables:

• Module list with responsibility descriptions
• Preliminary cross-module RPC interface list
• Module owner assignment table

Step 3｜ER Design & Data Modeling

Architect tasks:

• Design Entity (database tables) and their fields for each module
• Define Relations (foreign key associations) between Entities
• Determine index strategies (unique indexes, regular indexes)
• Design Enums and Value Objects (EO)

AI assistance:

• Use DomainArchitect to create Entity, Relation, Enum, and EO in Toco
• Typical prompt: “Create a member table under the member module with the following fields: id, phone, password, status (enum: ACTIVE/INACTIVE), created_time, with a unique index on the phone field”

Key principles:

• ⚠️ ER design is the foundation of the entire project. Modifications later are extremely costly and must be thoroughly reviewed
• One Entity can only belong to one module; cross-module table sharing is prohibited
• Enums and value objects should be fully defined at this stage

Deliverables:

• Complete ER diagram (including all Entities, fields, indexes, and associations)
• Enum list
• EO list

Step 4｜Aggregate Design & Domain Object Division

Architect tasks:

• Organize related Entities into Aggregate Objects (BO) centered around aggregate roots
• Define the boundaries and invariant rules of each aggregate (e.g., order total = sum of all line item amounts)
• Clarify transaction boundaries for write operations (one write plan can only operate within a single aggregate)

AI assistance:

• DomainArchitect helps identify aggregate boundaries and generates BO structure suggestions
• Typical prompt: “In the order module, the order table is the aggregate root and order_item is its child entity. Help me design the BO structure and invariant rules for this aggregate”

Deliverables:

• Aggregate division documentation
• Business invariant rules list for each aggregate

Step 5｜Modeling Review & Baseline Confirmation

All team members participate, architect leads the review:

• Are module boundaries clear with no overlapping responsibilities?
• Does the ER design cover all business scenarios?
• Are cross-module dependencies reasonable with no circular dependencies?
• Are aggregate boundaries correct and transaction scopes appropriate?
• Are Enums and EOs complete?
• Does each module owner clearly understand their boundaries?

💡 Once the review passes, the ER model enters “baseline” status. In principle, no architectural-level modifications are allowed afterwards. Any changes must go through the review process again.

Phase 2: Parallel Module Development

👤 Owner: Each module developer (parallel)　⏱️ Mode: Parallel, modules are independent and non-interfering　✅ Done When: All interfaces in the module are implemented, self-tested, and documentation updated

Each developer is responsible for the complete development of one module, following the steps below:

Step 6｜Module Interface Design

Developer tasks:

• Understand the business requirements and ER structure of the module
• Analyze what HTTP API interfaces need to be provided
• Use TocoAI for interface analysis to break down the specific interface list

AI assistance:

• Provide module requirements to TocoAI for automatic interface list analysis
• Review each interface analysis result one by one to confirm parameters, return values, pagination mode, etc.

Recommendations:

• When the number of interfaces > 5, save to the workspace first, then open sessions in batches
• Process interfaces in new sessions, no more than 5 interfaces per batch; complex interfaces should have their own dedicated session

Deliverables:

• Interface list (including URI, parameters, and return value descriptions)
• Pending task list saved to the workspace

Step 7｜Detailed Design (DesignerAgent)

Developer tasks (open a new session for each batch of interfaces):

• Create design elements such as DTO, VO, QTO, BTO required by the interfaces
• Design ReadPlan and WritePlan
• Confirm service layer method (RPC/SERVICE) signatures
• If the module needs to be called by other modules, complete the public RPC interface definition

AI assistance:

• Let PlannerAgent output a detailed plan first, then enter DesignerAgent for execution after Review
• Typical prompt: “Based on the interface plan above, complete the design element creation for the member module”

Notes:

• ⚠️ If new Entity fields or table structure changes are needed at this stage, the architect must be notified for Review
• After design elements are created, code regeneration must be triggered

Deliverables:

• All design elements for this batch (DTO/VO/ReadPlan/WritePlan/API)
• Generated framework code

Step 8｜Business Logic Coding (DeveloperAgent)

Developer tasks:

• Fill in the business logic on top of the framework code generated by Toco
• Focus on the following extension points:

Deliverables:

• Fully runnable business code for this batch of interfaces
• Self-tested interfaces

Step 9｜Cross-Module RPC Integration

Developer tasks:

• If the module needs to call other modules, subscribe and call via public RPC interfaces in public_service
• If the module needs to be called by other modules, confirm that public RPC interfaces are correctly exposed
• Communicate with the owners of related modules to confirm interface contracts

Notes:

• Directly injecting Service classes from other modules is strictly prohibited; only public_service interfaces can be used
• If the dependent module is not yet developed, Mock return values first and integrate once the other party is done

Deliverables:

• Cross-module call code
• RPC interface integration records

Step 10｜Module Self-Testing & Wrap-up

Developer tasks:

• Complete functional self-testing of all interfaces in the module
• Check boundary conditions, exception scenarios, and concurrency safety
• Update module-related documentation

Self-Test Checklist:

• All interfaces pass normal case tests
• Parameter validation exception scenarios are handled correctly
• Cross-module RPC calls work correctly
• FULLY_LOCKED code has not been manually modified
• No hardcoded direct references to cross-module Services

Phase 3: Integration & Release

👤 Owner: Architect + All developers　⏱️ Mode: Sequential, centrally coordinated

Step 11｜Integration Testing

• Once all modules are complete, deploy to the integration testing environment
• Perform end-to-end testing following business flows (e.g., register → place order → pay → refund complete chain)
• Focus on cross-module data consistency and transaction boundaries
• Issues found should be fixed by the responsible module owner

Step 12｜Architecture Review

The architect performs an architecture-level review of the final code:

• Are module boundaries respected (no out-of-boundary calls)?
• Do all cross-module dependencies go through public_service?
• Is the ER model consistent with the final code?
• Are there any unauthorized Entity modifications?

Step 13｜Release

• Follow the standard release process; not expanded here

Role Responsibilities Summary

Key Collaboration Principles

💡 Core Philosophy: Architecture is global; development is local. The quality of the architect’s modeling determines the ceiling of the entire project, while the independence of developers’ modules determines parallel efficiency. Steps 1–5 are led by the architect; Steps 6–10 are completed by developers. The Toco platform, combined with company processes (domain modeling ensured by architects, business code filled in by developers), naturally supports this collaboration model.

Of course, there is no single best process — only the one most suited to your organization and specific context. This document is a recommendation; feel free to adapt the process to your company’s actual situation.