Life-long computer geek, including hardware and software, networking and programming. Passionate about C#, but seeing the light with functional programming, e.g. F#, Haskell, Lisp, etc.
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.
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.
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.