Is your feature request related to a problem? Please describe.
The Bio-OS is constructed around the workspace concept, which is nicely understood. The main capability provided right now can be recapped into 3 parts: storage, workflow execution, jupyter notebook. So it confuses me all the time that there are four domain entities in the workspace bounded context, with notebook server & submission in their own context. In my consideration, the submission entity/context is tightly coupled with the workflow entity since submissions and run history are clearly only attached to the workflow (from what I've observed).
I understand that this division is based on the tech and performance consideration, so the workflow execution part should be a subdomain and therefore a microservice (just like the notebook server), but static records such as run and submission can be moved into workflow subcontext or workspace, and in web interface/cli the run history should be wrapped inside workflow as a child command.
The core dev said that cromwell and jupyterhub is in the supporting subdomains, and the core subdomain contains three bounded contexts. What I think is one bounded context is enough and the workspace could be classed as the core subdomain, while notebook server and workflow server as the supporting subdomains, with jupyterhub/cromwell as infrastruture inside. Forgive my laziness to not draw a UML to illustrate. (Maybe sometimes later😂)
Describe the solution you'd like
Explanation and/or discussion in detail about the system design, and whether we can improve it.
Is your feature request related to a problem? Please describe. The Bio-OS is constructed around the workspace concept, which is nicely understood. The main capability provided right now can be recapped into 3 parts: storage, workflow execution, jupyter notebook. So it confuses me all the time that there are four domain entities in the workspace bounded context, with
notebook server&submissionin their own context. In my consideration, thesubmissionentity/context is tightly coupled with theworkflowentity since submissions and run history are clearly only attached to the workflow (from what I've observed).I understand that this division is based on the tech and performance consideration, so the workflow execution part should be a subdomain and therefore a microservice (just like the
notebook server), but static records such asrunandsubmissioncan be moved intoworkflowsubcontext orworkspace, and in web interface/cli the run history should be wrapped insideworkflowas a child command.The core dev said that cromwell and jupyterhub is in the supporting subdomains, and the core subdomain contains three bounded contexts. What I think is one bounded context is enough and the
workspacecould be classed as the core subdomain, whilenotebook serverandworkflow serveras the supporting subdomains, with jupyterhub/cromwell as infrastruture inside. Forgive my laziness to not draw a UML to illustrate. (Maybe sometimes later😂)Describe the solution you'd like Explanation and/or discussion in detail about the system design, and whether we can improve it.