CODEWITHSUNDEEP
domain-driven-design
yido
yido

Reputation: 307

Implementing Domain Driven Design Cost

I am using DDD in my project and liked the powerful Idea it has and being independent of my back end DB design. And I am also making use of MVP model in my front END. Yet lately, I am having performance issue of translating Models to Models (>>1000 objects at a time) like:

  1. From EF Repository Model to Domain Model
  2. From Domain Model to ViewModel

And the same trip I should go to persist a single object on DB. Is this the cons of implementing this model or is there any way of reducing this cost that I should follow.

Upvotes: 1

Views: 348

Answers (2)

pwc
pwc

Reputation: 446

Probably it is a good case to use CQRS.

When you separate read model, you can ommit current mapping layers and hydrate it directly from your data source.

Upvotes: 3

Dave New
Dave New

Reputation: 40062

There should be an insignificant performance hit from "mapping" your domain aggregate to your Entity Framework data model and vice versa.

But why are you mapping 1000s of objects at a time? I don't understand your requirements or your domain, but it sounds like there may be an issue in your design. Why would you even need so many aggregates in memory?

I suggest that you profile your database. I suspect that you are eagerly loading unnecessary data from your database into memory. I would recommend using ExpressProfiler if you don't already have such a tool.

Upvotes: 2

Related Questions