How many businesses still use spreadsheets as part of their business operations? The reality is that they are used even at the highest levels in mu...
For further actions, you may consider blocking this person and/or reporting abuse
There is no universal solution that fits all cases. DDD works best in certain scenarios and not well in others.
Also, you should fairly point out that configuration-based solutions have negative trade-offs that your customers will notice. For one thing, they typically require an extensive setup and training process to master the implications of the configuration options. Depending on how deep those configuration options are, that may even require training and keeping on staff an expert in your software. Many times end users also have increased training times because such systems give enough "freedom" for users to do the wrong things with the data. So they need to undergo training to learn the right way. These are non-trivial requirements to place on customers.
Because of the "freedom" such systems enable to administrative users, over time the system can rot into a convoluted mess of determining how all the ad hoc rules interact. As a dev, coding new features against such a system while maintaining the integrity of all the user's ad hoc rules is also a daunting challenge, and not the kind I would consider enjoyable.
For some use cases, these trade-offs are minimal and it is a good design to use. I am happy for you that it works for your product. But by no means is it universally the best option, nor is DDD always the wrong choice. Everything has a circumstance where it will flourish... it just may not be one you are facing today.
I also agree with what Kasey mentioned specially the downsides of the configuration based systems which tend to evolve into ESB like system after a while.
And on the top of that the samples given on the article are integration and orchestration which usually implemented in Application Layer in DDD terminology. These areas usually should have simple businesses like transformation, aggregation ... or keeping the simple orchestration state. So if you do not any businesses in theses areas other than what I menti
oned, it is totally ok to skip DDD complexities
I would argue that a DBMS is actually designed around a domain--that being the efficient storage and retrieval of data. That simple. That's why you don't see other "business domain" logic in a DBMS--it's not its domain in the first place. The only purpose of a DBMS is the efficient storage and retrieval of data. Period.
And I agree with @kasey, there is no universal solution that fits all cases. I also agree with most of everything else said in the comment with respect to how all that external configuration can lead to problems. In my organization we moved away from that architecture because of the exact problems Kasey mentioned. And in other organizations I have dealt with software that strived to be as general (universal) as possible. And usually what resulted was a piece of software that was so general it need a lot of additional work to make it more specific to meet a particular purpose, i.e. the generalized software was next to useless. Not to mention, it was confusing for both users and developers.
To be clear, I cannot say that in all situations that a solution consisting of generalized software is bad; and nor can I say that in all situations DDD is good. As anyone who's been around long enough comes to know, the answer is always "It depends." In my particular situations, generalized software did not result in bringing value. I have also been in other situations where DDD did not bring value either. You must have context to understand whether a particular design methodology and/or architecture will result in realizing the expected business value.
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...
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.
"The first reason domain driven development is a bad idea is that it encourages you to build business logic into the application."
Literally, what? --- maybe you should acknowledge some scope here because this is literally what many of us are paid to do. This would be a terrible idea if you were building software for people outside of your company (e.g. generic solutions like database software, or products that meant to be pulled off the shelf), but for many of us if not most of us, we build software to run the companies we work for. In that case, the statement that building business logic into the software is a bad thing is patently absurd. That doesn't make DDD bad, that makes using DDD in a non-domain context bad. Like trying to tighten a lug nut with a banana.
"for many of us if not most of us we build software to run the comanies we work for." Yes yes, so do I, but by using a platform which is not strongly tied to any domain you can deliver systems which are configured at runtime that are easily adaptable and flexible. No development life cycle. This is what agile means. You can make modifications in runtime systems. The more you hard code the business rules the less flexible the software. Configure business rules instead. Configure data structures. Configure integrations, queries, visualizations and so on. In a way this is still 'development', only it hands power back to users.
The more business logic you add on your application, the easiest it is to test them. If the stakeholders wanted something to configure, that should have clearly stated so. Giving them something "not strongly tied" it's basically giving them something anemic (considered an anti - pattern for the sole reason of a system being able to be used by oranges and apples at the same time, and quite very always having weird behaviour for both at the same time)
The less flexible software, the easier it is to change. The fastest you're pipelines and safer you'll feel -on teh development cycle - where solving something could literally 5 minutes.
Flexibility can be very quickly substituted by ambiguity.
The only reason you think this way is because you lack knowledge for building clean code. You need to know about clean architecutre/ hexagonal architecture, DDD and CQRS patterns, OO patterns and SOLID.
With those tools, you won't need to argue thater argue to "not have logic tied" to the business.
On the other hand, for "anemic" solution there are aplenty, they are called wordpress, drupal, CMS, etc. Then is the job of the "site builder" using the given tools to create a solution. What happens with this? Very rapidly you reach a non scalable point, specific use cases are very hard because there's always something very specific domain thing that will need custom development, and that is the source of all frustration of all the developers that don't know better.
I am sorry but this article is dangerous, in encourages bad practices in the industry, it will lead to greats amount of frustration, of developers being caught in a Sisyphus kind of development where firefighting is the normal, and where the code is completely so non understandable since it's used as "generic" as possible.
" ... software to run the companies we work for..." , well that seems to be more often than not: Excell.
Peter is not arguing he can develop a SINGLE SYSTEM, so configurable it will be a solution to all the reaquierements.
I am curious how is DDD leading to reusability? Any kind of reusability.
I can describe anything as a model. That does not mean I have to map that model 1:1 to "business objects", to deliver the functionality required.
Generic concepts and types? Generic OO Business Patterns? Well there is no cook-book of recipes for that. So lets not go there. (SAP is based on that idea. It takes a year or more to configure it for one customer)
One thing I noticed with DDD. It is well suited to "Parroting the Architecture". Just skim over the book, have every project code structured into "Domains", "Features" and "DataAccess" and suddenly you are an Architect or even "Head of Engineering". Just stick to the Book ;)
How can you guarantee your business logic works as intended in such a scenario? You can't write tests for it, since it isn't part of your codebase.
It sounds to me like you've set up a framework. Probably a good one, but that's not what it takes to meet your users' expectations. I also have trouble to believe runtime configuration can cover every single possible need, business-wise.
Your points against microservices are fair enough, given they're not an universal solution. Neither is DDD (even if it's a global step forward in theory, as it encourages software developers to not intertwine business logic with technical layers). Neither is your own - but I know you agree with that.
To address Kasey and Craig's points. I am not claiming that we can create a single solution to meet all needs, rather that software should be designed around function rather than domain. Therefore video editor software cannot be created from a forms and data type application because it is dealing with video functionally. However, many software projects begin with requirements tightly coupled with the domain. Often this leads to software unnecessarily coupled to the domain, and thus limits itself. Imagine the designer of Word getting requirements to write a specific style of letter and writing a word processor around that specific style of letter for a particular industry.
The critique that pushing the domain into configuration leads to complexity in the configuration is valid. In fact the configuration becomes the place you define the domain rules. Just like you can write scripts inside Excel the systems I'm writing allow embedded Javascript which runs server side, and can be replaced with a REST call, by the right administrator of course. Where once there were developers and users we now have a more diverse environment where developers deliver core functionality and business analysts can construct new systems using these tools.
This article was primarily addressing the practice of using the domain as the foundation of the system. In the past this was necessary because of the way databases were static. Adding complex structures at runtime was not possible. Now it is possible, and with this possibility goes new opportunities to dramatically improve development efficiency.
This is not just a supposition. I'm now running the second project using the same software, despite the domains being totally different. We are now looking to develop it into a generally available tool for the entire organization.
Database servers are an example of good architectural design where their purpose of storing data is not confused with the domain the database will be used for.Do you know that databases have also their own domain? A table, a column, the type of it, etc. All of this could be modeled and have it's domain. When you get an error from the database, that is their business logic. Their app, their program is about persisting data, and that's what they do best.
This "empowering users" you are referring to, the equivalent with the database, it's not that I can "create table of my own domain", that's the service they provide, the same service you should provide application you're developing.
The equivalence is having a database not know what even is a table or a column - because those are their domain concepts - so it will be "the empowered user" having to tell it those concepts, and pray that those will eventually properly coded. Does it make sense? of course not, and I am honestly afraid what kind of deliverables you give...
I'm afraid this is an example of the kind of contempt many developers have for expert users. Tables and columns are indeed concepts useful to those building solutions. But not everyone needs to know a general purpose computer language and build a custom application to store some data and apply some business rules. Much of the safety can be built into this class of solution, such as permission and logging. You're not talking to someone ignorant of coding or SQL; its been my bread and butter for over twenty five years. But you can't be afraid of new ways of doing things.
Now you can rename the app « administrators » to « developpers ». You just dumped complexity on your users.
Why not create a template project based on a framework like Spring Boot and ask them to setup their business rules? Yeah, that’s called development but at least they may be able to write some tests.
In 14 years in this field, I think this is the most naive article I ever read.
Some of the pushback is good here while some seems over thought. I hear Peter saying something like .. “In the case of a document store, don’t make it 3 times in 3 apps. Rather configure each to use the same generic one.” Now it is 2023 and 12 factor apps and micro services are common. Cloud style Lambda apps are reasonably doable for small shops.
I would suggest another interpretation is “don’t let techno dogma override common sense…”
What I continue to see is common use cases, such as REST over DBs, where the code base is not doing anything unique. It is simply a crystalized implementation against a specific fixed schema. Having a runtime definable data store means you don't need to spend time maintaining basic data storage APIs. And if you want a new structure / table it is done in minutes. Companies such as Salesforce are pretty much doing this.
"Each of these web servers are connected to a database server to store the data for that service. Imagine that there is a head crash on one of the database servers. " - Wrong architecture decision. Each microservice (or domain) should have their own database cluster with replication, not "a database".
" 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." - you can have different (auto)scalling policies for each group of servers, based on usage (for example, the users service/domain probably is much more used for reading, than the payment service).