5 ms·

Hard pass. I'll stick with Domain Driven Design, though for simple systems, old school monoliths are fine. Complex enterprise systems end up being a cluster-F w

Hard pass. I'll stick with Domain Driven Design, though for simple systems, old school monoliths are fine. Complex enterprise systems end up being a cluster-F when driven into a monolithic state or when the primary architectural foundation is some database. Of course any traditional relational DBA would love this article. But relational databases are an architectural anti-pattern. Don't start with the data. Start with the domains.

RcouF1uZ4gsC 5y ago
> But relational databases are an architectural anti-pattern. I disagree. I think relational databases are such a mature technology that you should definitely start with them if you possibly can. They are flexible enough that they can accommodate a lot of different applications. In addition, relational databases are performant and scalable enough that unless you reach MAGAF scale, they will likely work for you.
rozularen 5y ago
what other type of database do you use then instead of relational databases?
- ChicagoDave 5y ago
  Depending on the requirements of the domain, you can use relational, graph, document, or key/value. Let the domain decide.
cerved 5y ago
You can have domains in a single database using schemas
ratww 5y ago
> But relational databases are an architectural anti-pattern. This is such an inflammatory and ignorant statement that I don't really have any other answer other than to call it pure bullshit. Relational Databases are probably one of the few popular areas of our profession that are not only backed by formalisms and research that tell us to do it correctly, it is also proven to work in practice: it is the de facto backbone of most financial, commercial, government systems and, heck, even military, but also even of modern FAANG-style big tech. Sure, they're boring. And it takes time to learn. And normalisation might has its costs but we can know them all upfront, and we know where and how to break them. The (currently trendy) horizontal scalability is indeed non-trivial with them, but vertical and horizontal-via-sharding are easier than most ad-hoc solutions. But the boredom pays off in guarantees, and to learn you have 50 years of mature material to rely on. (This is not to say that non-relational databases are useless. Both have its uses, but they're both only really useful if you properly understand them) Complex enterprise systems are complex for reasons beyond the technology. Often due to processes and bureaucracies. Those complexities often end up turning into "essential complexity" in systems, and Domain Driven Design is not able to reduce such essential complexity, and nothing can. Nor is Domain Driven Design incompatible with relational databases, especially the tactical part, which is often the major selling point of DDD. It is entirely possible to model domains within databases, and is entirely common. Also, DDD is not a guarantee of success. If anything, it has not proven itself nowhere near as much relational databases have. As much as the original idea of DDD is good (again, especially the tactical part), it I see it often become rationalisation for the same old architecture astronautics that cause excessive incidental complexity. For people wanting architectural complexity, I can completely understand the distaste for something simple like "keeping it in the DB". It completely negates all the fancy technical patterns prized by developers. This is not to discount the original idea and techniques of DDD: merely saying that the excuse "relational databases can be bad if not well done" applies as often, if not more, to the practice of DDD.
- HelloNurse 5y ago
  Relational databases work so well that they are also highly effective when used badly. So it's easy to succumb to temptation and take the easy path (I don't want to add three tables to keep it normalized... let's allow this column to be null, the applications can check... another field for the second phone number, we'll see about the third one... make your queries non-isolated or we could have a deadlock...) with apparently good results, and then when technical debt comes home the architecture amateurs can blame the tools instead of themselves.
  - ChicagoDave 5y ago
    It's not just about poorly designed relational models. It's also about impedance mismatch when converting relational models to business models. You end up automating that using object-relation mappers and this leads to a hardened and immovable design. Eventually, the business will ask for a significant change and the tech staff will put forth their costly assessment for that change. Then the business has to decide to either rewrite the system or to pay for the tech debt or (worst case) hack the new features into the existing architecture. Many times, it all gets punted and the business lives with the complexity. I've seen this way too many times to back off of my assessment. Relational models do not, in the long term, enable an agile business model. It is an anti-pattern even if it takes years to reveal itself as such.
    - ratww 5y ago
      I've seen several complex businesses with incredibly complex processes and systems that were entirely based on relational databases, and changes were always fast in the database side. The database itself is agile and it is easy to modify and migrate. The problem always lies on excessive abstractions and patterns on the backend side. Which really isn't solved anywhere by any strategy other than keeping things damn simple. Your descriptions of "impedance mismatch when converting relational models to business models" and "automating mappers that leads to a hardened and immovable design" are a precise example of that: OOP patterns muddying the development process and causing problems in unrelated parts of the system (in this case the database). Of course, keeping things simple and programming in a way that fits the relational model is incredibly difficult for developers that have been trained to believe that complexity is the answer to all problems future and past. So the resort for those people is to keep pestering management to throw the baby (relational databases) with the bathwater (relational mappers and other related OOP patterns).
deleted 5y ago
[deleted]
ahdh8f4hf4h8 5y ago
Honestly, object oriented design is the anti-pattern here. Almost none of the benefits promised in the 1990's and 2000's have come to pass, and for most applications type hierarchies are of little help. For most applications, having a really good relational data model, and controlling data updates through a service/microservice will give most of the benefits of "object oriented" design without any of the drawbacks. The service will act as a "live object", data integrity will be preserved, data science modeling will be easy, and the application can be designed using whatever tomorrow's preferred platform of the day is, or even some low code stuff for simple applications.
dimgl 5y ago
> But relational databases are an architectural anti-pattern. Say what bro? Surely this is sarcasm. Relational databases make up the foundation of most of the services you use today. Even poorly designed relational database schemas will work in production.
arcbyte 5y ago
There really is no data. Only the domain.

RcouF1uZ4gsC 5y ago

> But relational databases are an architectural anti-pattern. I disagree. I think relational databases are such a mature technology that you should definitely start with them if you possibly can. They are flexible enough that they can accommodate a lot of different applications. In addition, relational databases are performant and scalable enough that unless you reach MAGAF scale, they will likely work for you.

rozularen 5y ago

what other type of database do you use then instead of relational databases?

ChicagoDave 5y ago
Depending on the requirements of the domain, you can use relational, graph, document, or key/value. Let the domain decide.

cerved 5y ago

You can have domains in a single database using schemas

ratww 5y ago

> But relational databases are an architectural anti-pattern. This is such an inflammatory and ignorant statement that I don't really have any other answer other than to call it pure bullshit. Relational Databases are probably one of the few popular areas of our profession that are not only backed by formalisms and research that tell us to do it correctly, it is also proven to work in practice: it is the de facto backbone of most financial, commercial, government systems and, heck, even military, but also even of modern FAANG-style big tech. Sure, they're boring. And it takes time to learn. And normalisation might has its costs but we can know them all upfront, and we know where and how to break them. The (currently trendy) horizontal scalability is indeed non-trivial with them, but vertical and horizontal-via-sharding are easier than most ad-hoc solutions. But the boredom pays off in guarantees, and to learn you have 50 years of mature material to rely on. (This is not to say that non-relational databases are useless. Both have its uses, but they're both only really useful if you properly understand them) Complex enterprise systems are complex for reasons beyond the technology. Often due to processes and bureaucracies. Those complexities often end up turning into "essential complexity" in systems, and Domain Driven Design is not able to reduce such essential complexity, and nothing can. Nor is Domain Driven Design incompatible with relational databases, especially the tactical part, which is often the major selling point of DDD. It is entirely possible to model domains within databases, and is entirely common. Also, DDD is not a guarantee of success. If anything, it has not proven itself nowhere near as much relational databases have. As much as the original idea of DDD is good (again, especially the tactical part), it I see it often become rationalisation for the same old architecture astronautics that cause excessive incidental complexity. For people wanting architectural complexity, I can completely understand the distaste for something simple like "keeping it in the DB". It completely negates all the fancy technical patterns prized by developers. This is not to discount the original idea and techniques of DDD: merely saying that the excuse "relational databases can be bad if not well done" applies as often, if not more, to the practice of DDD.

HelloNurse 5y ago
Relational databases work so well that they are also highly effective when used badly. So it's easy to succumb to temptation and take the easy path (I don't want to add three tables to keep it normalized... let's allow this column to be null, the applications can check... another field for the second phone number, we'll see about the third one... make your queries non-isolated or we could have a deadlock...) with apparently good results, and then when technical debt comes home the architecture amateurs can blame the tools instead of themselves.
- ChicagoDave 5y ago
  It's not just about poorly designed relational models. It's also about impedance mismatch when converting relational models to business models. You end up automating that using object-relation mappers and this leads to a hardened and immovable design. Eventually, the business will ask for a significant change and the tech staff will put forth their costly assessment for that change. Then the business has to decide to either rewrite the system or to pay for the tech debt or (worst case) hack the new features into the existing architecture. Many times, it all gets punted and the business lives with the complexity. I've seen this way too many times to back off of my assessment. Relational models do not, in the long term, enable an agile business model. It is an anti-pattern even if it takes years to reveal itself as such.
  - ratww 5y ago
    I've seen several complex businesses with incredibly complex processes and systems that were entirely based on relational databases, and changes were always fast in the database side. The database itself is agile and it is easy to modify and migrate. The problem always lies on excessive abstractions and patterns on the backend side. Which really isn't solved anywhere by any strategy other than keeping things damn simple. Your descriptions of "impedance mismatch when converting relational models to business models" and "automating mappers that leads to a hardened and immovable design" are a precise example of that: OOP patterns muddying the development process and causing problems in unrelated parts of the system (in this case the database). Of course, keeping things simple and programming in a way that fits the relational model is incredibly difficult for developers that have been trained to believe that complexity is the answer to all problems future and past. So the resort for those people is to keep pestering management to throw the baby (relational databases) with the bathwater (relational mappers and other related OOP patterns).

deleted 5y ago

[deleted]

ahdh8f4hf4h8 5y ago

Honestly, object oriented design is the anti-pattern here. Almost none of the benefits promised in the 1990's and 2000's have come to pass, and for most applications type hierarchies are of little help. For most applications, having a really good relational data model, and controlling data updates through a service/microservice will give most of the benefits of "object oriented" design without any of the drawbacks. The service will act as a "live object", data integrity will be preserved, data science modeling will be easy, and the application can be designed using whatever tomorrow's preferred platform of the day is, or even some low code stuff for simple applications.

dimgl 5y ago

> But relational databases are an architectural anti-pattern. Say what bro? Surely this is sarcasm. Relational databases make up the foundation of most of the services you use today. Even poorly designed relational database schemas will work in production.

arcbyte 5y ago

There really is no data. Only the domain.