Modeling a business’s processes does not equate to modeling a business’s data.
Starting with modeling data will immediately cripple software engineers from building what the business needs.
Starting with business models and then deciding what data storage is appropriate is a more practical way of designing software. Operational data very often fits in schema-less document storage.
Relational databases are excellent tools for analytics and reporting.
I stopped architecting software with relational databases “first” 7 years ago and will never go back.
Document databases are highly adaptive and denormalized data is inherently faster.
I’ve since found very rare cases where a boundary requires a relational database.
Starting with modeling data will immediately cripple software engineers from building what the business needs.
Starting with business models and then deciding what data storage is appropriate is a more practical way of designing software. Operational data very often fits in schema-less document storage.
Relational databases are excellent tools for analytics and reporting.
I stopped architecting software with relational databases “first” 7 years ago and will never go back.
Document databases are highly adaptive and denormalized data is inherently faster.
I’ve since found very rare cases where a boundary requires a relational database.
Welcome to my Domain-Driven Design rant.