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.
One of the more pervasive issues with modern software development is domain coupling. Most tools for software development encourage baking the domain directly into source code. This encourages us to develop software which is less flexible than it needs to be.
The original driver for this pattern was databases and their inflexible structures. Database schema along with object oriented software encouraged data structures to be modeled in code. This became accepted orthodoxy in terms of how to build software. The ER diagram was often the first artifact of development, and everything else flows from it.
Several years ago I rejected the orthodoxy and began writing business applications based on schemaless data storage and zero domain coupling to software. This has made the software far more flexible and adaptable for a wide variety of applications.
The downside is that many development tools and libraries are built around fixed schema and domain binding. For example, GraphQL libraries assumed a static schema once deployed. I have to develop a mechanism to dynamically update the schema at runtime. I no longer use object relational mapping as there are no domain objects. There are in fact still data objects, but they are not tied to the domain of the application.
The real benefit of this approach is that it gives power back to the users so they are in the drivers seat. In a majority of cases domain binding is premature, a consequence of a unintentional acceptance of domain binding without thought because modern tools assume it.
EU ๐ช๐บ | Art, Tech & Good Vibrations ๐คณ | Founder of แดแดแดแดสสแดแดก ๐ hellotomorrow.agency โข Just started working on a new endeavour ๐ usepoe.app โข Follow me on Twitter!
Location
Brussels, Belgium
Work
UX Engineer, Product Manager, sometimes Designer at Self
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.
One of the more pervasive issues with modern software development is domain coupling. Most tools for software development encourage baking the domain directly into source code. This encourages us to develop software which is less flexible than it needs to be.
The original driver for this pattern was databases and their inflexible structures. Database schema along with object oriented software encouraged data structures to be modeled in code. This became accepted orthodoxy in terms of how to build software. The ER diagram was often the first artifact of development, and everything else flows from it.
Several years ago I rejected the orthodoxy and began writing business applications based on schemaless data storage and zero domain coupling to software. This has made the software far more flexible and adaptable for a wide variety of applications.
The downside is that many development tools and libraries are built around fixed schema and domain binding. For example, GraphQL libraries assumed a static schema once deployed. I have to develop a mechanism to dynamically update the schema at runtime. I no longer use object relational mapping as there are no domain objects. There are in fact still data objects, but they are not tied to the domain of the application.
The real benefit of this approach is that it gives power back to the users so they are in the drivers seat. In a majority of cases domain binding is premature, a consequence of a unintentional acceptance of domain binding without thought because modern tools assume it.
Very interesting. Do you have an article (or anything like that) with more detailed description of the approach?
Same here, I'm curious to see what it looks like in practice.
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.