0

First I'd like to say that my standard approach to developing software is probably typical to a lot of developers... I have Services which are rich in behavior but have no state and I have Objects (Beans) which have only state and no behavior (I think this is typically referred to as an Anemic Domain Model).

I've decided to try a Domain Driven Design (DDD) approach on a new project however I have a couple of issues which are really niggling me.

  1. I have an existing 3rd party database which my organisation uses (and which is tightly coupled to the business and there is nothing I can do about this: I don't want any comment mentioning how this could lead to issues if the 3rd party changed their data model... I know!!). I've created hibernate Entities to represent the data however I'm unsure how to convert this into a internal model representation which is in keeping with the principles of DDD (i.e. A rich domain model which encapsulates data access).

  2. There must be patterns for this sort of issue but I'm finding it hard to find any. This leads me to believe that I'm probably doing something in the wrong way (i.e. not the way it is typically approached).

My current strategy is to:

  • Identify the key entities amongst the hibernate Entities and to try and package these together with a related Values objects (This has been really difficult, I believe because I'm starting with data and creating a domain... any suggestions on a way to approach this would also be welcome)
  • For each package I've identified I've created a repository to manage the entity
  • In each repository (e.g. StudentHibernateRepository) I grab hold of the hibernate entities I need and wrap them in a proxy class.
  • In each proxy class I add my business rules which pass through to use the wrapped hibernate entity as a data source (again trying to make my code behavior rich).

If anybody has experience in doing something similar could you please share experience/patterns. It would also be helpful if you could reflect on the strategy I've taken.

Cheers,

JLove

raven-king
  • 1,550
  • 2
  • 18
  • 40

1 Answers1

0

A rich domain model is only part of DDD. It may not be worthwhile to adapt an existing and worse yet frozen data model to a rich domain model. Persistence ignorance is a desirable aspect of DDD, however in practice, compromises are often made and technical concerns such as persistence cannot simply be deferred.

One problem with the proxy approach is an increase in mapping complexity. Your proxy entities will have to delegate to the underlying NHibernate mapped objects and in certain scenarios this could get ugly.

Without a domain model however, you can still reap many of the benefits of DDD. I would first try to identify the core domain and any sub-domains and the corresponding bounded contexts. Then, encapsulate all use cases in application services which would in turn delegate to your NHibernate mapped entities. You won't have the benefit of behavior rich entities, but I've found that to be a fair trade-off in these types of scenarios.

eulerfx
  • 36,769
  • 7
  • 61
  • 83