Hi, as in your case you have a relational database for persisting aggregates, naturally you will have an overhead of decomposing your aggregate into tables and vice/versa.
But specifically answering your question:
- If you need to look for something extra before creating an order I’d just inject a repository that contains the data is needed and then create the order based on the data returned.
As an example, let’s propose a scenario in which we want to create an order based on a previous shopping kart. The command would only contain the shopping kart id. Once the command is handled, I’d inject the shopping kart repository, query by id, create the order and store it properly.
There are many ways of doing it, but think of you handler as your application layer that coordinates your domain objects.
Keep in mind that a handler should represent a transaction unit and try to keep it as simple as possible. If it becomes something bigger, then you need to think better on the design of your process/application.
- As I said before, by using relational database you naturally have an overhead of mapping it. If you can, I’d really suggest storing your aggregate as documents (I wrote about it before). But in case you are in a brown field already, it will depend on the EF version that you are using.
- In case it is EF Core, you can use its fluent API to map the columns of your table to your properties (even if they’re private). Check more here.
- In case it is EF 6 or inferior, then your classes are probably tied to the way this version works, like, public getters and setters, virtual properties for relationship mapping and etc. If you think you need and it is important refactoring it, I’d suggest decoupling your domain model of your persistence model and creating a mapping layer on your infrastructure that takes care of translating a domain model into persistence model and vice versa. But I’d really evaluate if this is needed, because it is quite a big overhead.
- Finally, to restore/persist it, the handler would just ask for the order repository and call a method: Store. Under the hood, the implementation would take care of infrastructure concerns.