\n",
"\n",
" \n",
" - We have a simple interface between persistent storage and our domain model.
\n",
" - It’s easy to make a fake version of the repository for unit testing, or to swap out different storage solutions, because we’ve fully decoupled the model from infrastructure concerns.
\n",
" - Writing the domain model before thinking about persistence helps us focus on the business problem at hand. If we ever want to radically change our approach, we can do that in our model, without needing to worry about foreign keys or migrations until later.
\n",
" - Our database schema is really simple because we have complete control over how we map our objects to tables.
\n",
" \n",
" | \n",
"\n",
" \n",
" - An ORM already buys you some decoupling. Changing foreign keys might be hard, but it should be pretty easy to swap between MySQL and Postgres if you ever need to.
\n",
" - Maintaining ORM mappings by hand requires extra work and extra code.
\n",
" - Any extra layer of indirection always increases maintenance costs and adds a \"WTF factor\" for Python programmers who’ve never seen the Repository pattern before.
\n",
" \n",
" | \n",
"