Separate object models into domain model and DTO #2702
Conversation
|
What's the driving factor behind this change, if you don't mind my asking? DTO/DO separation tends to add a lot of complexity in my experience. |
core/src/main/java/com/netflix/conductor/domain/WorkflowDO.java
Outdated
Show resolved
Hide resolved
core/src/main/java/com/netflix/conductor/domain/WorkflowStatusDO.java
Outdated
Show resolved
Hide resolved
core/src/main/java/com/netflix/conductor/core/dal/DomainMapper.java
Outdated
Show resolved
Hide resolved
core/src/main/java/com/netflix/conductor/core/dal/DomainMapper.java
Outdated
Show resolved
Hide resolved
apanicker-nflx
force-pushed
the
object_model_separation
branch
2 times, most recently
from
f5ca4f7
to
916a52f
Compare
apanicker-nflx
force-pushed
the
object_model_separation
branch
from
916a52f
to
9830fca
Compare
@indiv0 While it does add some complexity at the beginning, it completely decouples the conductor state machine from the user-facing APIs. Some of the internal fields used by the state machine (eg. executed, subWorkflowChanged etc) are currently exposed to the users because the same object model is used by the state machine and the DTO layer. This separation allows the evolution of the state machine and features therewith, without impacting the user. |
| @@ -184,3 +184,14 @@ configure(allprojects - project(':conductor-grpc')) { | |||
| } | |||
| } | |||
| } | |||
|
|
|||
| ["cassandra-persistence", "core", "redis-concurrency-limit", "test-harness"].each { | |||
There was a problem hiding this comment.
Should this configuration be done for all projects? We will end up adding Spock tests for most of the modules.
There was a problem hiding this comment.
we can extend this to all java projects, i only added the ones that currently have spock tests
apanicker-nflx
changed the title
Pull Request type
Separate object models into Data Transfer Object and Domain Object
Changes in this PR
A new object model is introduced that will be used by the state machine and all internal processes within Conductor. All external facing APIs and client will continue to use the existing object model. A new class
ModelMapperis introduced to provide the translation between the domain object and the data transfer object.The separation of domain object from the data transfer object completely decouples the conductor state machine from the user-facing APIs. Some internal fields that are only used by the state machine (e.g. executed, subWorkflowChanged etc) are currently exposed to the users because the same object model is used by the state machine and the DTO layer. This separation allows the evolution of the state machine and features therewith, without impacting the user. It also helps abstract away any of the state machine complexities while providing a clean and lean object model for the user to work with.
Additionally, because of the way the object models are intertwined currently, payloads stored in external storage need to be manipulated (uploaded/downloaded) depending on the call stack, either from state machine or api layer, so that large payloads are not sent over the wire and are only available for use within the state machine. The separation of object models enables the state machine to download the payload from external payload storage once during a given workflow evaluation without needing to examine the call stack. The API layer does not need to deal with the large payloads since the model mapper handles the mapping to the DTO.