In theory, Domain Driven Design advocates modeling based on the reality of business as relevant to your use cases. I'm not going to talk so much about the theory here, in reality the technical concepts of DDD means most of your business domain logic are within your domain classes and fields are been set private, something like this:
// (domain class with private fields)
In order to manipulate the values of name or description, you would need to use SetName() or SetDescription() methods via the object itself, doesn't seems have a problem here.
var tenant = await _repo.tenants.GetByGuidIdAsTracking(request.Dto.Id);
You probably building a asp.net core web api where entitties are retrieved/persisted across database with ef core framework and entities would be returned as a result. If you are new to DDD, you will probably encounter these common issues.
- Private fields cannot be directly accessed via ef core database context in a linq statement
- The domain class when return directly from an api controller as a api result will not have the private fields indicated in the returned result
For problem number 1, just use the EF.Property as provided by ef core framework.
For problem number 2, you probably can map it to a DTO class with public fields and return the DTO class as the api result instead of directly returning the domain class as the result set. You probably want to use automapper in this case. I happen to found out that the below GetName() function will map the value of private field _name to the destination object field name. Somehow asp.net core has this mapping to a shadow property mapping built in.
These are the common things in DDD you probably need to get used to when compared to tradditonal approach. Have fun coding!
Note: Partial content reconstructed from search snippets — please verify against original source if any code blocks or details look incomplete.