I take issue with the idea that Domain Models, Entities, or Models are just simple objects that mirror database records. Ideally, the business layer should be blissfully unaware of the underlying database. It’s the infrastructure layer’s job to translate these Models/Entities into database records. Sure, for small or even medium applications with straightforward CRUD operations, this overlap might seem true. But when business requirements get more complex, we often need sophisticated data structures to represent a single business element. These structures can’t always be squeezed into a single database record.
I take issue with the idea that Domain Models, Entities, or Models are just simple objects that mirror database records. Ideally, the business layer should be blissfully unaware of the underlying database. It’s the infrastructure layer’s job to translate these Models/Entities into database records.
Sure, for small or even medium applications with straightforward CRUD operations, this overlap might seem true. But when business requirements get more complex, we often need sophisticated data structures to represent a single business element. These structures can’t always be squeezed into a single database record.
In all my teams over the last n-years, "infrastructure" always means cloud resources.
Thanks, that's good to know. That speaks to my point about terminology.
Yup, in my mind Infrastructure is hardware and how it's setup. It actually had very little to do with code...