feat: pass entity to get projection ids

[the-avid-engineer]

Consider the following graph:

graph BT
    Leaf1 --> Branch1
    Leaf2 --> Branch1
    Leaf3 --> Branch2
    Leaf4 --> Branch2
    Branch1 --> Root1
    Branch2 --> Root1

Loading

It has a tree-like structure that you will probably find in most bounded contexts in some shape or form. As of #29 you can represent each of these nodes as an entity in a single transaction repository.

If each branch node's entity has the Id of every ancestor node's entity, this change allows you to easily build a projection of the entire tree.

When the ProjectionSnapshotTransactionSubscriber runs, it will not have to run queries to get the ancestor node's entity ids.. you can just check what kind of object the entity is and pull the appropriate property.

The following partial code could be used to map all of these entities to a single projection.

public record Leaf(Id RootId, Id BranchId, Id LeafId, ...);

public record Branch(Id RootId, Id BranchId, ...);

public record Root(Id RootId, ...);

public class RootGraphProjectionStrategy : IProjectionStrategy<RootGraph>
{
    public Id[] GetProjectionIds(Id entityId, object entity)
    {
        if (entity is Leaf leaf) {
            return new[] { leaf.RootId };
        }

        if (entity is Branch branch) {
            return new[] { branch.RootId };
        }

        if (entity is Root root) {
            return new[] { root.RootId };
        }

        throw new NotSupportedException();
    }
}

Note

I recommend against storing the entire data model in one repository - you should probably stick to a repository per bounded context - but there is no reason a bounded context must only own a single entity, and therefore there is no reason the transaction repository must only contain a single entity type! When it comes to APIs for accessing the graph of data - obviously GraphQL seems like a great idea, and the concept of schema stitching and linking seems very promising.