2

I'm still trying to understand DDD. Let's say I have an immutable VO PresentationSlide. Because it is immutable it can be easily shared and used by different entities. But what happens if I try to map this to a database. In EntityFramework I could model the PresentationSlide as a ComplexType, meaning the properties of the shared PresentationSlide are mapped to the tables using it. This is fine, but a Slide might be quite large and therefore I'm wasting space, if it used/reference several times.

As an alternative approach I could map a PresentationSlide to a separate table and reference it. Because it is immutable this should also work. But now, if I modify a Presentation, I have to copy the content of the old PresentationSlide and create a new instance. If there are a lot of changes, I will soon have a lot of orphaned PresentationSlides in my database.

Isn't this a problem? Is there a solution? Should I implement a custom periodical 'Cleanup orphaned PresentationSlides'-Task?

krombi
  • 504
  • 1
  • 4
  • 15
  • You could always do cleanups based on events such as `PresentationChanged` or you could perform periodic cleanups. Still, sometimes it may be too expensive to use a VO although there's no real need for an identity. It feels natural to me that a `PresentationSlide` would be mutable. How often do you really share a `PresentationSlide` between presentations or even re-use the same slide in a single one? – plalx Sep 10 '15 at 13:06
  • There is something I don't understand. Having **shared** `PresentationSlide` means that when a user create a new `Presentation` he can choose to attach a existing `PresentationSlide` to the `Presentation` instead of add a new one. But then you must keep orphan `PresentationSlides` for future new/modified `Presentations`. – jlvaquero Sep 14 '15 at 11:57

1 Answers1

0

First you should think about ownership and life cycle of the PresentationSlide within your domain model. Always make sure you follow your model semantics when doing performance or storage optimization.

  • I'd start out with duplicating each PresentationSlide within its entity. This is just the natural way to do, because that's what you do in your domain model, too.

  • Put metrics in place that enable you to make an informed decision about the storage optimization. E.g. go with the duplication approach and calculate the space wasted due to duplicates after some time in production.

  • Only if you really have a problem, do the storage optimization. Otherwise you've become victim of Premature Optimization.

If you really need to make an optimization, I think the approach you mention is a reasonable one. Create a separate table, and regularly clean up PresentationSlides that are not referenced anymore.

Community
  • 1
  • 1
theDmi
  • 17,546
  • 6
  • 71
  • 138