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.
"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".
Please read about rich domain. What you're saying is just having an anemic domain, that works very well with CRUD, and this is repetitive. You know that DDD is the alternative of CRUD?
It's quite impressive how you can write such an ignorant article. Please read the books 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.
It's hard not to assume ignorance with what you write:
So let us think about scalability and availability in these two systems. Imagine that there is a head crash on one of the database servers. In a functional architecture the other two servers take over and everything trucks along as normal while the damaged server is brought back into service. What happens to the domain driven architecture? Well one of the API will go totally offline. Not only that but you will need to restore the database server from backup, potentially with data loss.
Okay, but surely domain driven architecture is better for scaling? Well lets think about it. With the domain driven architecture all the hits for a specific service will go to the same servers. That means that if you are unfortunate enough to get a rush on one specific API it will get over loaded. But with a functional architecture any web server can service any call and the load is spread across multiple web servers and database servers.
So the same for here.
And what's the advantage you can scale some parts of teh system that need to be scaled without having to scale the whole system (with the cost it takes). Just a small advantage.
=====
What usually happens when people start building real systems and run into this problem is the gurus come in and tell them they have been doing it wrong. They didn't quite understand the one true path. It seems our guru never really evaluated whether breaking an architecture apart based on the domain was a clever idea in the first place, or indeed whether using the domain as the foundation for application boundaries was a sensible.
You can read again this one amazon.com/gp/product/B09B5L4NVT, where it explains the advatnages or disadvantages of partitioning the architecture domain based or technical based. (also the architecture books). Take into account Conway's Law too.
Also, read this amazon.com/gp/product/B07B9F83WM, the chapter about architecture, where they measured the performance of many organizations and condensed the results in this book (and still surveys are going on). Here's a quote:
It appears that these characteristics of architectural decision, which we refer to as testability and deployability, are important in creating high performance. To achieve these characteristics, design systems that are loosely coupled. [..]
Architectural approaches that enable this strategy include the use of bounded contexts [..]
But in this case, they're talking of a big organization with many teams, not about a single project, which the other architectural book will give you better insights.
=====
quote here everything about the flexibility.
you might want to read this quote from here amazon.com/gp/product/B07LCM8RG2 (page 62 - chapter 2, secion: "Refactoring, Architecture and Yagni")
One way of dealing with future changes is to put flexibility mechanisms into the software. As I write some function, I can see that it has a general applicability. To handle the different circumstances that I anticipate it to be used in, I can see a dozen parameters I could add to that function. These parameters are flexibility mechanisms- and, like most mechanisms, they are not a free lunch. Adding all those parameters complicates the function for the one case it's used right now. [..]. I find I often get my flexibility mechanisms wrong-either because the changing needs didn't work out the way I expected or my mechanisms design was faulty. Once I take all that into account, most of the time my flexibility mechanisms actually slow down my ability to react to change.
======
So I get it, you had a good experience before DDD was mainstream (taking into account that the first book was published in 2003 - amazon.com/gp/product/B00794TAUG- and you had that role in 2006) - and I'd say not even 2013, with the red book from Vaughn vernonr( amazon.com/gp/product/B00BCLEBN8) DDD wasn't maintream (as if it was now! it's not!)
And actually, you managed what Martin Fowler couldn't: get the flexibility mechanism right. Or build a good abstraction, so the system could be used somewhere else. You know you can do that with DDD too.
I am surprised you didn't get any of the pain of that system. I guess whenever there's a bug you tell the user "you configured it badly".
Because DDD sparked against the solution your writing here. It's all about simplifying the code so it's understandable and therefore maintainable. But it goes together with a lot of other practices (devops, continuous integration, good testing, things that sparked too with extreme programming - to sum it up broadly).
Let me quote the blue book (the first one from Eric Evans) (preface! "Design Versus Development Process)
This book is not tied to a particular methodology, but it is oriented toward the new family of "Agile development processes". Specifically, it assumes that a couple of practices ar ein place on the project[...]:
Development is iterative. Iterative development has been advocated and practiced for decades, and it is a cornerstone of Agile development methods. There are many good discussions in the literature of Agile development and Extreme Programming[..]
Developers and domain experts have a close relationship
So that's a big difference with the experience you had, where maintenance doesn't seem to be part of the picture. In that case, honestly, you're not wrong, I'd consider your approach.
Still, only somebody ignorant could have written this article. That's why I assume ignorance. It's more, I'm certain you haven't read any of the books I'm quoting here, yet you feel entitled to write a blog post against them. I'm not sure who's being disrespectful here.
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.
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...
You just made the nth framework, congratulations
"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".
Please read about rich domain. What you're saying is just having an anemic domain, that works very well with CRUD, and this is repetitive. You know that DDD is the alternative of CRUD?
It's quite impressive how you can write such an ignorant article. Please read the books first.
Its rude to assume ignorance just because someone happens to disagree. Also not a very constructive approach.
It's hard not to assume ignorance with what you write:
you can have exactly the same thing at a "micro" service level. You can read this: amazon.com/gp/product/B09H2H5QKC, and this amazon.com/gp/product/B09B5L4NVT to understand how's that a possibility.
So the same for here.
And what's the advantage you can scale some parts of teh system that need to be scaled without having to scale the whole system (with the cost it takes). Just a small advantage.
=====
You can read again this one amazon.com/gp/product/B09B5L4NVT, where it explains the advatnages or disadvantages of partitioning the architecture domain based or technical based. (also the architecture books). Take into account Conway's Law too.
Also, read this amazon.com/gp/product/B07B9F83WM, the chapter about architecture, where they measured the performance of many organizations and condensed the results in this book (and still surveys are going on). Here's a quote:
But in this case, they're talking of a big organization with many teams, not about a single project, which the other architectural book will give you better insights.
=====
you might want to read this quote from here
amazon.com/gp/product/B07LCM8RG2 (page 62 - chapter 2, secion: "Refactoring, Architecture and Yagni")
======
So I get it, you had a good experience before DDD was mainstream (taking into account that the first book was published in 2003 - amazon.com/gp/product/B00794TAUG- and you had that role in 2006) - and I'd say not even 2013, with the red book from Vaughn vernonr( amazon.com/gp/product/B00BCLEBN8) DDD wasn't maintream (as if it was now! it's not!)
And actually, you managed what Martin Fowler couldn't: get the flexibility mechanism right. Or build a good abstraction, so the system could be used somewhere else. You know you can do that with DDD too.
I am surprised you didn't get any of the pain of that system. I guess whenever there's a bug you tell the user "you configured it badly".
Because DDD sparked against the solution your writing here. It's all about simplifying the code so it's understandable and therefore maintainable. But it goes together with a lot of other practices (devops, continuous integration, good testing, things that sparked too with extreme programming - to sum it up broadly).
Let me quote the blue book (the first one from Eric Evans) (preface! "Design Versus Development Process)
So that's a big difference with the experience you had, where maintenance doesn't seem to be part of the picture. In that case, honestly, you're not wrong, I'd consider your approach.
Still, only somebody ignorant could have written this article. That's why I assume ignorance. It's more, I'm certain you haven't read any of the books I'm quoting here, yet you feel entitled to write a blog post against them. I'm not sure who's being disrespectful here.