Beautiful article.
The question for me on scalability is: do companies want to scale in their domain or beyond their domain like the software you built later did?
Of course, the latter is of greater risk, somewhat in the lines of what a product person would call product differentiation. Possible different products at a higher cost. A higher cost of development time especially in abstracting all of that logic to suit for whatever future needs.
In as much as I always tend to the generic lines philosophically in most things I do(dev.to/femolacaster/generalist-or-...), my bias is reserved when it comes to those things that are done for financial revenue🤑.
The model proposed by you may be the best for large complex systems, systems with less clarity of domain, and open-source projects. And yes I agree with Craig that a DBMS actually has its domain and any scaling outside its intended purpose may not be that significant to the users. And this already exists in the largesse of ERP systems today where the runtime logic is abstracted to concepts like workflow, jobs, and tasks. Going your suggested route seems to me like building a BPM or an RPA tool.
But in this day we live? Where you need to sell the idea and not an abstraction of the idea asap. A time of MVPs. In the light of at least let it do one thing well, early investors, early adopters, early failures….we really should think of DDD.
PS: Also, the need for domain experts goes beyond contributing to the business logic but to all composition of the idea including the architecture or any function that was suggested to be abstracted. Think of accountants saying this is the kind of "excel" we want.
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.
The point of this environment is to be adaptable, to enable fast MVP projects, but to build in all the features that you would expect in the foundations, such as security, audit trails, complex reporting and data manipulation out of the gate. Domain binding forces you to write repetitive code that is more or less identical in each app, the only difference is the model it binds to. Spring Security makes life better in the Java space, but you still end up with a large number of apps running in a micro service bound to the domain.
I agree with your points, Peter. I am thinking that building in all the features that you would expect in the foundations, such as security, audit trails, complex reporting, and data manipulation out of the gate would take more time needed for an actual MVP. You may say this is done only once and can be reused but even these foundational features could have special domain needs. Multi-FA security is more tailored to financial domains, for instance, verbose audit logs are tailored to information systems with high deletes or journaling domains. The point is there might be an over or under engineering building the foundations first.
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.
My code is open source - GPL3. Feel free to utilize or even contribute back. It's Java/SpringBoot. Codebase is a little dated in some respects. I'm working on a new UI which isn't part of the core project.
Beautiful article.
The question for me on scalability is: do companies want to scale in their domain or beyond their domain like the software you built later did?
Of course, the latter is of greater risk, somewhat in the lines of what a product person would call product differentiation. Possible different products at a higher cost. A higher cost of development time especially in abstracting all of that logic to suit for whatever future needs.
In as much as I always tend to the generic lines philosophically in most things I do(dev.to/femolacaster/generalist-or-...), my bias is reserved when it comes to those things that are done for financial revenue🤑.
The model proposed by you may be the best for large complex systems, systems with less clarity of domain, and open-source projects. And yes I agree with Craig that a DBMS actually has its domain and any scaling outside its intended purpose may not be that significant to the users. And this already exists in the largesse of ERP systems today where the runtime logic is abstracted to concepts like workflow, jobs, and tasks. Going your suggested route seems to me like building a BPM or an RPA tool.
But in this day we live? Where you need to sell the idea and not an abstraction of the idea asap. A time of MVPs. In the light of at least let it do one thing well, early investors, early adopters, early failures….we really should think of DDD.
PS: Also, the need for domain experts goes beyond contributing to the business logic but to all composition of the idea including the architecture or any function that was suggested to be abstracted. Think of accountants saying this is the kind of "excel" we want.
The point of this environment is to be adaptable, to enable fast MVP projects, but to build in all the features that you would expect in the foundations, such as security, audit trails, complex reporting and data manipulation out of the gate. Domain binding forces you to write repetitive code that is more or less identical in each app, the only difference is the model it binds to. Spring Security makes life better in the Java space, but you still end up with a large number of apps running in a micro service bound to the domain.
I agree with your points, Peter. I am thinking that building in all the features that you would expect in the foundations, such as security, audit trails, complex reporting, and data manipulation out of the gate would take more time needed for an actual MVP. You may say this is done only once and can be reused but even these foundational features could have special domain needs. Multi-FA security is more tailored to financial domains, for instance, verbose audit logs are tailored to information systems with high deletes or journaling domains. The point is there might be an over or under engineering building the foundations first.
My code is open source - GPL3. Feel free to utilize or even contribute back. It's Java/SpringBoot. Codebase is a little dated in some respects. I'm working on a new UI which isn't part of the core project.
bitbucket.org/cheetah100/gravity/s...