Reputation: 2178
I'm trying to learn the concept of DDD. I have made a project which i use the database first approach. In the infrastructure i have added an edmx file witch i have chosen to auto generate the entites. Now in the "Domain" I'm trying to create aggregates.
But here i got some problems. I´m trying to create a aggregate named "User" but User already exists in the entites that the ef autogenerated. Should i rename the aggregate "User" to something else and when getting data from the db map it from db entites to the aggregate.
I'm doing it wrong ? Or shouldn't i autogenerate the entities or is the enties aggregates ?
Plz advise and help.
Upvotes: 5
Views: 2808
Reputation: 270
From my point of view, Domain-Driven Design and "database first" are antithetic. Domain-Driven design focuses on complex behavior, and a data model focuses on the static structure of the data.
If I had the privilege to start from a clean situation, I wouldn't make it more complicated than necessary by creating a legacy database first. Consider that DDD is oriented to complex domain, where discovery and learning is part of the process.
To support a continuous learning process it's better to rely on software components which are more specifically designed for evolution (like an Object-Oriented Domain Model that can be under cheap Unit Tests) instead of a database design whose evolution is definitely more expensive.
Nobody can do everything right at the beginning. So I'd better start with something with a very little throwaway cost.
Upvotes: 3
Reputation: 70721
If you want to be true to DDD, you should model your domain objects to be independent of your persistence solution. DDD handles persistence through repositories. Don't use the "entities" generated by EF as your domain model; instead design your own model and implement a repository that makes use of EF for persistence.
Upvotes: 10