Another observation: in real applications there is often are issues caused by leaking abstractions. For example, in theory replacing one type of repository with another (for example, MySQL with NoSQL) should be easy. But implicit knowledge about particular DB type capabilities often leaks into the repository API and then up to outer layers in the form of ordering/pagination/aggregation/etc. As a consequence switching to another DB is possible but only if this is the same type of DB (i.e. relational, for example).
I agree. The main problem with software architecture (abstractions, patterns, even solid principles) is that most of the times some people understand them in a way that is not complete. They understand the main idea, but they don't know how to do it properly and what they get is a bad abstraction system, with huge coupling.
What you mentioned, I have seen a lot of that in .NET/C#. The most used ORM is Entity Framework, and in several cases, I saw like developers were using the database model as Entities in DDD. And you know, that is the beginning of the chaos where the ORM data model is coupled to the domain and also the Application Services are coupled to the Data Model... and the tech debt increases in every task creating a nice spaguetti code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Another observation: in real applications there is often are issues caused by leaking abstractions. For example, in theory replacing one type of repository with another (for example, MySQL with NoSQL) should be easy. But implicit knowledge about particular DB type capabilities often leaks into the repository API and then up to outer layers in the form of ordering/pagination/aggregation/etc. As a consequence switching to another DB is possible but only if this is the same type of DB (i.e. relational, for example).
I agree. The main problem with software architecture (abstractions, patterns, even solid principles) is that most of the times some people understand them in a way that is not complete. They understand the main idea, but they don't know how to do it properly and what they get is a bad abstraction system, with huge coupling.
What you mentioned, I have seen a lot of that in .NET/C#. The most used ORM is Entity Framework, and in several cases, I saw like developers were using the database model as Entities in DDD. And you know, that is the beginning of the chaos where the ORM data model is coupled to the domain and also the Application Services are coupled to the Data Model... and the tech debt increases in every task creating a nice spaguetti code.