The database is not an entity, nor the data model. The database is mechanism to store data.
While relational tables may be convenient for certain forms of data access, there is nothing architecturally significant about arranging data into rows within tables. The use cases of your application should neither know nor care about such matters.
Many data access frameworks allow database rows and tables to be passed around the system as objects. Allowing this is an architectural error.
Databases are disks.
programmers have been plagued by one fatal trait of disk technology: Disks are slow.
What if your data is stored in RAM? How will you organize that data?
You'll organize it into linked lists, trees, hash tables, stacks, queues, or any of the other myriad data structures
At any rate, you will leave the data in the form of files or tables.
This reality is why I say that the database is a detail. It’s just a mechanism we use to move the data back and forth between the surface of the disk and RAM. The database is really nothing more than a big bucket of bits where we store our data on a long-term basis.
when it comes to data storage, it’s a concern that can be entirely encapsulated and separated from the business rules. Yes, we need to get the data in and out of the data store quickly, but that’s a low-level concern.
The reason I was wrong was because our customers expected us to have a relational database. They didn’t know what they would do with it. They didn’t have any realistic way of using the relational data in our system. But it didn’t matter: Our customers fully expected an RDBMS.
The data is significant. The database is a detail.
These oscillations move back and forth between putting all the computer power in central servers and putting all computer power out at the terminals. We’ve seen several of these oscillations just in the last decade or so since the web became prominent. At first we thought all the computer power would be in server farms, and the browsers would be stupid. Then we started putting applets in the browsers. But we didn’t like that, so we moved dynamic content back to the servers. But then we didn’t like that, so we invented Web 2.0 and moved lots of processing back into the browser with Ajax and JavaScript. We went so far as to create whole huge applications written to execute in the browsers. And now we’re all excited about pulling that JavaScript back into the server with Node.
Framework authors know their own problems, and the problems of their coworkers and friends. And they write their frameworks to solve those problems—not yours.
In effect, the author is asking you to marry the framework—to make a huge, long-term commitment to that framework. And yet, under no circumstances will the author make a corresponding commitment to you.
- The architecture of the framework is often not very clean.
- The framework may help you with some early features of your application. But it may be not scalable as the product matures.
- The framework may evolve in a direction that you don't find helpful.
- A new and better framework may come along that you wish you could switch to.
Don't marry the framework!
you should not sprinkle
@autowiredannotations all throughout your business objects. Your business objects should not know about Spring.
Keep the framework behind an architectural boundary if at all possible, for as long as possible.