CODEWITHSUNDEEP
c#domain-driven-design
Nerf
Nerf

Reputation: 938

DDD - POCOs. First step

It is my first time in DDD. In company we don't have "domain master". I have only read about DDD I need to implement domain with DDD aproach.

So, I know that in domain there are no place for Database features. But if I would use my domain with Entity Framework and NOSQL database. With EF i need to make collections virtual and in constructor alloce as new. This is bad in DDD?

My code: 

 public abstract class Merchant : AggregateRoot
{
    public Company Company { get; set; } // Entity

    public string CIF { get; set; }
    public string NIP { get; set; }
    public string Status { get; set; }

    public Address Address { get; set; } // Entity
    public Group Group { get; set; } // Entity
    public virtual ICollection<Brand> Brands { get; set; } // Brand is entity

    protected Merchant()
    {
        this.Brands = new List<Brand>();
    }
}

Upvotes: 1

Views: 361

Answers (2)

Dmitry S.
Dmitry S.

Reputation: 8513

I would be more concerned about having public setters than a protected default constructor or a virtual property. The problem with that is can lead to an inconsistent state of the entity. For example, you may want to validate the address properties to make sure all the required properties are set and the postal code corresponds to the state/country. Another example would be status transitions; once the entity reaches a "final" status, it cannot be changed anymore.

While you can create separate validators for entities and use them before you persist the entities, it defeats the purpose of a rich domain model.

There are a few ways to get around it. You can create DTO objects that mirror the database schema and use hydrators to populate the entities (with protected/internal property setters) from those DTOs assuming the data in the database is always in the consistent state. All the new changes will have to go through entity methods to get validated. Then you would hydrate the DTOs based on the latest entity data and persist it.

CQRS with event sourcing is a more advanced alternative of this that persists all changes as an immutable log/event-store rather than (only) the latest data snapshot. But that is not something that is necessary for every domain scenario.

Upvotes: 1

guillaume31
guillaume31

Reputation: 14072

There are multiple shades of opinion about that issue in the DDD space.

To me, the primary measure of "persistence ignorance" is :

Will a change in my database break things in my domain layer, forcing me to open up the domain model and modify stuff to fix it ?

If we look at your example, the answer is clearly no.

It would have been the case if you had for example data annotations in your entity class referring to table or column names, or if you relied on mapping by convention and changed the Merchant table name to Reseller in the DB. But having a default constructor and virtual property doesn't make your domain class more fragile in the face of database changes.

Then you have a secondary question, a less critical one IMO :

Is the ORM a hindrance in my implementing domain entities just the way I want and as DDD-compliant as they need to be ?

This one is a bit more challenged. It might be, if the ORM forces you to add operations that can leave the domain object in an inconsistent state. I wouldn't consider a parameterless constructor as prone to that though, since it can be private and thus impossible to shoot yourself in the foot with. Same with setters.

Some consider that small traces such as the need for virtual and parameterless constructor violate DDD, because your entities are not pure any more, they contain oddities caused by the presence of an ORM. Therefore, you should create a second "persistence" model to leave the domain model untainted. I don't. I think most of the time it's not worth the tradeoff in terms of complexity - you can live with the small quirks as long as the first rule of persistence ignorance holds.

Upvotes: 4

Related Questions