Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
At another client I found that it was also useful, despite the use case being radically different to the original use case. We began making modifications to the code, but in a private repository, not the public one. Since then it has undergone major changes, but I have not yet been able to get it released.
I do not suggest trying to install Gravity because the dependencies are hideous. The current version is light years ahead so I'm trying to get the current client to release the modifications back to the public repo. There is a demo system on the devcentre.org site.
I know this is a bit of a sob story and not terribly useful. Once I get it released I will be making some detailed demonstrations and tutorials.
All this said, the basic principle of domain decoupling can be applied. It doesn't mean not having a domain, just expelling it from code and into runtime configuration. This data structures, views, filtering, screen designs, widget configuration, data transformations all become runtime configs.
What this means is that you can have multiple 'applications' running on the same environment which deals with totally different domains, but running on the same servers. Rather than having domain tied microservices all servers are the same and can serve any request.
Use a back end database that is schemaless such as MongoDB. When I began I used JackRabbit JCR which was initially fine, but it forced me into some pretty nasty work arounds to various implications to using the JCR. MongoDB has been way better in a variety of ways, but the code on the public repo is still using JackRabbit.
Sorry I can't do better in terms of doing a real show and tell.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In 2013 I started a project code named 'Gravity'. It is a process automation system. In 2015 it was released as open source under the GPL.
devcentre.org
At another client I found that it was also useful, despite the use case being radically different to the original use case. We began making modifications to the code, but in a private repository, not the public one. Since then it has undergone major changes, but I have not yet been able to get it released.
I have made some videos about it.
youtube.com/playlist?list=PLvtptYK...
I do not suggest trying to install Gravity because the dependencies are hideous. The current version is light years ahead so I'm trying to get the current client to release the modifications back to the public repo. There is a demo system on the devcentre.org site.
I know this is a bit of a sob story and not terribly useful. Once I get it released I will be making some detailed demonstrations and tutorials.
All this said, the basic principle of domain decoupling can be applied. It doesn't mean not having a domain, just expelling it from code and into runtime configuration. This data structures, views, filtering, screen designs, widget configuration, data transformations all become runtime configs.
What this means is that you can have multiple 'applications' running on the same environment which deals with totally different domains, but running on the same servers. Rather than having domain tied microservices all servers are the same and can serve any request.
Use a back end database that is schemaless such as MongoDB. When I began I used JackRabbit JCR which was initially fine, but it forced me into some pretty nasty work arounds to various implications to using the JCR. MongoDB has been way better in a variety of ways, but the code on the public repo is still using JackRabbit.
Sorry I can't do better in terms of doing a real show and tell.