R – DDD Book, Eric Evans: What is meant by “The FACTORY should be abstracted to the type desired rather than the concrete class(es) created.”

domain-driven-designfactory-patternoop

In the book Domain Driven Design, by Eric Evans, in Chapter 6 in the section on "Factories" (page 139) it says the following:

"The two basic requirements for any good FACTORY are:

…

"2. The FACTORY should be abstracted to the type desired rather than the concrete class(es) created."

Could you please elaborate on what is meant by that statement about basic requirement number 2.

Best Answer

I think it means you should never return a concrete type from your factory.

For example, if you have an interface, let's say ISomething, an abstract class SomethingBase and finally some classes that implement this interface and inherit from the base class. Your creation method should return the interface type, instead of the base type. I think that is the idea.

public ISomething Create() { ... }

Instead of

public SomethingBase Create() { ... }

I hope it helps, Carlos.

Related Solutions

R – Domain Model Saving

In DDD, the domain entity doesn't take care of its persistence. You should not have a Save() method on it, ideally.

Your repository will have such a Save method, that takes an entity instance in parameter:

public class PersonRepository
{
   //...

   public void Save(Person person)
   {
      this.dataContext.Save(person);
   }

   //...
}

Depending on your stack, an ORM will handle the object saving, or you will end by constructing a query to save the person, or you will populate stored procedure parameters with from your instance values, etc.

If I understood correctly what you did, it may be necessary to move the persistence logic you put in the domain entities elsewhere, probably in repositories, or in the DAL used by your repositories.

R – Questions regarding Domain driven Design

There is a lot of debate about whether Repositories should be read-only or allow transactions. DDD doesn't dictate any of these views. You can do both. Proponents of read-only Repositories prefer Unit of Work for all CUD operations.
Most people (self included) consider it good practice that Entities are Persistent-Ignorant. Extending that principle a bit would indicate that they should be self-contained and free of all infrastructure layer services - even in abstract form. So I would say that calls to infrastructure services belong in Service classes that operate on Entities.
It sounds correct that Repository implementations and Factories (if any) should reside in the infrastructure layer. Their interfaces, however, must reside in the Domain Layer so that the domain services can interact with them without having dependencies on the infrastructure layer.
DDD doesn't really dictate whether you can skip layers or not. Late in the book, Evans talks a bit about layering and calls it Relaxed Layering when you allow this, so I guess he just sees it as one option among several. Personally I'd prefer to prevent layer skipping, because it makes it easier to inject some behavior at a future time if calls already go through the correct layers.

Best Answer

Related Solutions

R – Domain Model Saving

R – Questions regarding Domain driven Design

Related Topic