DDD handling of tables, repositories, and/or services

Question

Struggling to handle aggregates and aggregate roots when it comes to persisting. For example, I currently have a repository for each aggregate/table, but this is causing some issues in my service class.

Current JournalService

public class JournalService
{
    public JournalService(IUnitOfWork uow, IJournalRepository journalRepo)
    {
        this.uow = uow;
        this.journalRepo = journalRepo;
    }

    public void AddEntry(string journalName, Entry entry)
    {
        journalEntryRepo.AddEntry(journalName, entry);

        // there is no need for me to even have a journal class or any other domain class since repositories handle it all

        uow.Save();
    }

    private readonly IUnitOfWork uow;
    private readonly IJournalRepository journalRepo;
}

In the above example (what I'm currently using), it seems that there is no point to even have domain classes such as Journal. I could just handle everything by accessing the repositories. This feels very weird to me.. I almost feel that there is no domain.

Upon further research it seems that a repository should handle an aggregate root; and return the entire root that you then operate on. The issue I'm having with this proposed solution is, do I just call update on the aggregate root even though I've added objects (e.g. to a list)? Please see below:

Proposed New JournalService

public class JournalService
{
    public JournalService(IUnitOfWork uow, IJournalRepository journalRepo)
    {
        this.uow = uow;
        this.journalRepo = journalRepo;
    }

    public void AddEntry(string journalName, Entry entry)
    {
        Journal journal = journalRepo.FindById(journalName);

        journal.AddEntry(entry);

        journalRepo.Update(journal);   ///// am I handling this correctly here?

        uow.Save();
    }

    private readonly IUnitOfWork uow;
    private readonly IJournalRepository journalRepo;
}

// simple CRUD for repo
public interface IJournalRepository
{
    Journal Create();
    Journal FindById(string name);
    void Update(Journal journal);
    void Remove(Journal journal);
}

With the new solution, am I handling this correctly? Then I assume the IJournalRepository needs to handle figuring out what entries were added and then add them to the correct table? Although, this seems like a lot of extra work...

Answer 1

I almost feel that there is no domain.

Some domains are inherently anemic. If a given write doesn't depend on the current state, then there's no much to do beyond look at the incoming representation and ensure that it has the correct shape.

A big big hint here is that everything you need to know to perform the write to the database is contained within the request parameters themselves. All you are doing is taking a representation that was passed to you by the client, and transforming it into a message that you send to your persistence store.

So models and repositories and dancing bears aren't actually adding any business value.

Now - suppose you were to add another requirement: that each entry in the journal was supposed to be unique. That might be important to you in the case where you were receiving messages on an unreliable network, and needed to avoid adding any duplicate messages.

With some data stores, you might be able to just send it a WriteIfAbsent(entry) command, in which case this is still just a transformation.

But if you need to implement that logic yourself, now you need to load the history for this journal, compare this entry to those already present, add the entry if it is missing, and maybe store the result. In other words, the message you send to the data store now depends on the data that is already present in the store. In that case, you might want to separate the domain logic, which cares about the uniqueness of the list entries but doesn't care where the list is stored, from the persistence components that care where the list is stored but don't care at all about the uniqueness of the entries.

As the rules for what should be written get more complex, the value of (a) having all of those rules in a well defined boundary and (b) having that boundary be quickly testable without dragging in a bunch of overhead unrelated to the rules, goes up.

Answer 2

I think it seems weird to you because there isn't a repository (and service, for that matter) for Entry while it should, IMHO. Also, I believe you need a more "concrete" answer, so let me give you an example of how I would set it up:

(1) Do use domail model classes (Journal, Entry) and go with a generic repository design:

public interface IRepository<T, TId>  where T : class
{
    IEnumerable<T> FindAll();
    IEnumerable<T> FindBy(Expression<Func<T, bool>> predicate);
    void Save(T entity);
    void Add(T entity);
    void Remove(T entity);
}

(2) Provide one implementation for common repository functionality:

public abstract class Repository<T, TEntityKey> where T : class
{
    private readonly JournalDbContext _dbContext = new JournalDbContext();

    public void Save(T entity)
    {
        _dbContext.Entry(entity).State = EntityState.Modified;
        _dbContext.SaveChanges();
    }

    public void Add(T entity)
    {
        _dbContext.Set<T>().Add(entity);
        _dbContext.SaveChanges();
    }

    public void Remove(T entity)
    {
        _dbContext.Set<T>().Remove(entity);
        _dbContext.SaveChanges();
    }

    public IEnumerable<T> FindAll()
    {
        return _dbContext.Set<T>();
    }

    public IEnumerable<T> FindBy(Expression<Func<T, bool>> predicate)
    {
        return _dbContext.Set<T>().Where(predicate);
    }
}

(3) Interfaces for entity repository can be defined as follows. Any specific repository functionality should be here, too:

public interface IJournalRepository : IRepository<Journal, int>
{
    // anything besides the common repository functionality
    Journal FindByName(string name);
}

public interface IEntryRepository : IRepository<Entry, int>
{
    // ...
}

(4) Concrete repository implementations if any specific repository functionality is defined in (3) above or just the class declarations otherwise:

public class JournalRepository : Repository<Journal, int>, IJournalRepository
{
    public Journal FindByName(string name)
    {
        return FindAll().SingleOrDefault(j => j.Name == name);
    }        
}

public class EntryRepository : Repository<Entry, int>, IEntryRepository
{
    // ...
}

(5) Treat Entry as an aggregate root and have a service for it too so you can write (example based on your code):

public EntryService(IUnitOfWork uow, IEntryRepository entryRepo, IJournalRepository journalRepo)
{
    this.uow = uow;
    this.entryRepo = entryRepo;
    this.journalRepo = journalRepo;
}

public void Add(string journalName, Entry entry)
{
    Journal journal = journalRepo.FindByName(journalName);

    entry.JournalId = journal.Id;  // associate entry with the journal  

    entryRepo.Add(entry);   

    uow.Save();
}