That turned into an axcellent explanation! I wish I had came here earlier so I wouldn't had so much struggle with this topic, yet you made it even clearer.
Whilst I agree with @t3c1337 that some of your generalizations risk being too broad (e.g. domain models, etc, are the same or mirror database records) I still think you make a lot of great points. Ensuring that architecture remains practically helpful and accessible is so important.
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.
That turned into an axcellent explanation! I wish I had came here earlier so I wouldn't had so much struggle with this topic, yet you made it even clearer.
Whilst I agree with @t3c1337 that some of your generalizations risk being too broad (e.g. domain models, etc, are the same or mirror database records) I still think you make a lot of great points. Ensuring that architecture remains practically helpful and accessible is so important.
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...
Dtos Entities and Pocos are not the same things..