Domain Model Architecture for WorkflowRun #13963

Closed
opened 2026-02-21 19:14:48 -05:00 by yindo · 0 comments
Owner

Originally created by @laipz8200 on GitHub (May 16, 2025).

Originally assigned to: @laipz8200 on GitHub.

Self Checks

  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:)
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Part of #19429

Overview

This proposal outlines a significant architectural improvement to our workflow execution system by extending the domain-driven design approach implemented in #19428 to the WorkflowRun entity. The changes focus on creating a clear separation between our domain logic and persistence mechanisms, improving testability, and enhancing maintainability.

Proposed Solution

We propose implementing a domain model architecture with the following key components:

1. Domain Model for WorkflowRun

Create a dedicated domain entity (WorkflowRun) that represents the core business concept of a workflow run, independent of persistence concerns. This model will:

  • Encapsulate the essential properties and behaviors of a workflow run
  • Be free from infrastructure-specific details (tenant_id, app_id, etc.)
  • Provide a clean API for the core workflow logic
  • Align with the domain model architecture implemented for NodeExecution

2. Repository Pattern Implementation

Implement a WorkflowRunRepository interface and SQLAlchemy implementation to:

  • Translate between domain models and database models
  • Handle multi-tenancy and security concerns
  • Implement efficient caching at the repository level
  • Provide a consistent interface for data access
  • Follow the same pattern as the WorkflowNodeExecutionRepository

3. Workflow Cycle Manager Refactoring

Refactor the workflow cycle manager to:

  • Work exclusively with domain models
  • Delegate persistence concerns to the repository
  • Focus on orchestrating the workflow execution process
  • Improve testability through clearer separation of concerns
  • Remove direct database access and caching logic

2. Additional context or comments

No response

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @laipz8200 on GitHub (May 16, 2025). Originally assigned to: @laipz8200 on GitHub. ### Self Checks - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:) - [x] Please do not modify this template :) and fill in all the required fields. ### 1. Is this request related to a challenge you're experiencing? Tell me about your story. Part of #19429 ## Overview This proposal outlines a significant architectural improvement to our workflow execution system by extending the domain-driven design approach implemented in [#19428](https://github.com/langgenius/dify/issues/19428) to the WorkflowRun entity. The changes focus on creating a clear separation between our domain logic and persistence mechanisms, improving testability, and enhancing maintainability. ## Proposed Solution We propose implementing a domain model architecture with the following key components: ### 1. Domain Model for WorkflowRun Create a dedicated domain entity (WorkflowRun) that represents the core business concept of a workflow run, independent of persistence concerns. This model will: - Encapsulate the essential properties and behaviors of a workflow run - Be free from infrastructure-specific details (tenant_id, app_id, etc.) - Provide a clean API for the core workflow logic - Align with the domain model architecture implemented for NodeExecution ### 2. Repository Pattern Implementation Implement a WorkflowRunRepository interface and SQLAlchemy implementation to: - Translate between domain models and database models - Handle multi-tenancy and security concerns - Implement efficient caching at the repository level - Provide a consistent interface for data access - Follow the same pattern as the WorkflowNodeExecutionRepository ### 3. Workflow Cycle Manager Refactoring Refactor the workflow cycle manager to: - Work exclusively with domain models - Delegate persistence concerns to the repository - Focus on orchestrating the workflow execution process - Improve testability through clearer separation of concerns - Remove direct database access and caching logic ### 2. Additional context or comments _No response_ ### 3. Can you help us with this feature? - [x] I am interested in contributing to this feature.
yindo added the 💪 enhancement🌊 feat:workflow labels 2026-02-21 19:14:48 -05:00
yindo closed this issue 2026-02-21 19:14:48 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#13963