DDD: entities mapped to tables with lots of databse columns

Question

I am trying to follow the DDD approach to constructing entities where the properties have private setters and public getters and assignment is done through the constructor. The problem with this approach seems to be when you hit a table that has alot of columns, we have one that has 40 columns at least. It becomes a nightmare quickly. I found some articles that seem to point to either a Fluent Interface or Factory Pattern. It seems like 40 columns, though cleaner could still get out of control even with these patterns. The columns are relevant to the table design and don't violate SRP. Also, in trying to maintain the table size and maybe break the entity into smaller value objects based upon a logical grouping it still seems as if some of the value objects are going to be large. Could someone point me in the right direction of how to handle this situation without breaking DDD?

Answer 1

It is not to say that DDD is a bad fit for wide columns. Hiding a setter is also not a specific requirement of DDD, but plain old Encapsulation. (Protecting the modification of your data.) If you have to set a lot of these values and you find yourself muddling your code, then yes as you mentioned, move the construction to a Factory.

The secret of course is to not have any consuming code just assign any value to your domain object without following the proper "Domain Logic", hence the hiding of the setters. Sometimes of course you have to set all those values to your domain object, and the values come from some dto or mvc model or something, then using a Mapper class that can map/assign the values are a great way of keeping your consuming code clean.

You could even look into using something like AutoMapper by Jimmy Bogard: http://automapper.org/ which would also have no problem assigning values to private setters by the way.

If you are loading data using an ORM, some of them support private setters and/or backing fields. NHibernate for example allows this in your mapping file:

this.Property(x => x.Description, mapper => mapper.Access(Accessor.Field))

As per my comment, use something like AutoMapper to alleviate the writing of lots of mapping code. Wrap the implementation in an injectable class such as below which would allow you to replace the implementation in future without performing shotgun surgery.

public class ViewMapper<TModel, TDomain> : IViewMapper<TModel, TDomain>
{
    public TDomain MapToDomain(TModel dataItem)
    {
        return Mapper.Map<TModel, TDomain>(dataItem);
    }

    public List<TDomain> MapToDomain(IEnumerable<TModel> dataItems)
    {
        return dataItems.Select(this.MapToDomain).ToList();
    }

    public TModel MapToData(TDomain domainItem)
    {
        return Mapper.Map<TDomain, TModel>(domainItem);
    }

    public void MapToOriginalData(TDomain domainItem, TModel dataItem)
    {
        Mapper.Map(domainItem, dataItem);
    }

    public List<TModel> MapToData(IEnumerable<TDomain> domainItems)
    {
        return domainItems.Select(this.MapToData).ToList();
    }
}

AutoMapper is highly configurable, and should be able to handle most cases. Setup a mapper profile where you can tell it exactly what to do during mapping:

public class ViewItemProfile : AutoMapper.Profile
{
    protected override void Configure()
    {
        Mapper.CreateMap<Domain, View>()
            .ForMember(x => x.ErrorRequestId, y => y.MapFrom(z => z.ErrorTypeId))
            .ForMember(x => x.Irrelevant, y => y.Ignore());
    }
}