|
|
|
|
|
|
by functionstooge
1247 days ago
|
|
|
I'm curious, why would this be bad? I've generally always seen it as best practice to create classes in your domain model and try to write your ideal code and then have separate classes/DTOs that are used for communicating outside your domain model such as reading/writing to a database using an ORM or responding from an API with your ideal model for the consumer (since more often than not consumers don't need or want all of the cruft inside the domain model and your DB will likely have stored the information in a different format in a large system). I always love thinking of ways to simplify architecture though and I absolutely hate having classes/records that looks so similar though so I'm intrigued about a simpler solution if there is one? Domain Driven Design practices really encourage a bloated/complex architecture so I try to avoid it if possible but more often than not business requirements end up becoming so complex that I immediately fall back to those abstractions when the logic starts to get complex. |
|
|
But if there are little of those, no need to make them prematurely. Field mapping is something for EF Core mapper configuration or repository implementation to worry about, no need to do the job twice.
You often don't need separate "Host" and "Core" projects either. And if you ever need to migrate to a new hosting solution, it happens maybe once during application lifecycle, and even then it requires some effort.
Replace-all and IDE tools work just as fine if not better for this, no need to inflict easily avoidable pain simply because it looks consistent with "other" solutions that were written 10 years ago.