Clean Architecture: Loading data for the domain layer

Question

Let's say my domain has a User Entity that has a many to many relationship with itself representing "Friends"

public class User
{
    public int Id;
    public IEnumerable<User>? Friends;
}

In my application layer, I have a service that makes 2 User friend together and the only requirement is that they are not already friends:

public class UserServies
{
    public void AddFriend(int user1Id, int user2Id)
    {
        var user1 = _repository.GetUserById(user1Id);
        var user2 = _repository.GetUserById(user2Id);
        // use user1 and user2 in my domain layer to enforce business rules... 
    }
}

GetUserById would execute a SQL query like this:

SELECT u.* FROM Users u
LEFT JOIN Users_Friends uf ON u.Id = uf.UserId
LEFT JOIN Users f ON f.Id = uf.FriendId
WHERE u.Id = @Id

So far so good! But let's say the requirements changed and I would now need to access user1.Friends[i].Friends, this would result in a runtime error since we didn't load that data. I'm having trouble designing the domain layer in a way to avoid these kind of problems. I've thought of a few solutions, but none that makes me happy:

Eagerly load all relationships all the time

Bad: Performance wise it's terrible as it would require me to load all users all the time.

Only load the necessary data required by my domain business rules

Bad: This require way too much coupling between the data loader and the domain rules using said data. It would also be incredibly easy for a business rules change to result in a runtime error because someone didn't realize that the data loaded was no longer adequate (such as in my example above).

Use lazy loading in domain layer

Bad: Now the domain layer is no longer pure and is coupled to whatever persistence mechanism the infrastructure is using.

Use specific DAO object for each business operations

In this solution instead of dealing with a User, AddFriend would be dealing with a AddFriendUserDAO. AddFriendUserDAO would also need to have all its relationships be specific AddFriend DAO for it to works. Needless to say, it would increase the amount of code I need to write exponentially.

Do you have any recommended design pattern to deal with this scenario? I feel like it should be a pretty common scenario but I just don't know the right words to search for the solution.

Thanks.

Answer 1

The general approach here is going to be to model the interaction taking place. That is, make the implicit explicit. Let us add an additional concept to this system, FriendRequest, to carry some of that knowledge we are trying to crunch.

Here is an example of the general approach to use. I've extended our invariants to include an optional expiry and a max retry count to further exemplify how this approach can easily be extended to capture other constraints (and because "does something already exist" often doesn't feel like the kind of constraint that needs to be modeled explicitly as it is easily derived):

public class FriendRequest 
{
    public int senderId;
    public int receiverId;
    public int retryCount;
    public int? sentAt;
    public int? expiresAt;
    public int? acceptedAt;

    public void send(int? ttl) 
    {
        if (this.acceptedAt != null) throw new AlreadyFriends();
        if (this.retryCount + 1 > MAX_RETRY_COUNT) throw new GiveUpAlready();     

        this.sentAt = ...
        this.expiresAt = ...
        this.retryCount = ...
    }

    public void accept() 
    {
        if (this.sentAt == null) throw new NeverSent();
        if (this.isExpired) throw new Expired();
        if (this.acceptedAt != null) throw new AlreadyFriends();

        this.acceptedAt = ...
    }
}

public class UserService
{
    private FriendRequestRepository friends; //.find will return an "unsent" FriendRequest provided both users exist

    public void sendFriendRequest(int senderId, int receiverId)
    {
        var req = friends.find(senderId, receiverId); // may throw FriendRequestNotFound/UserNotFound
        req.send(FRIEND_REQUEST_TTL);
        friends.save(req);
    }

    public void acceptFriendRequest(int senderId, int receiverId)
    {
        var req = friends.find(senderId, receiverId); // may throw FriendRequestNotFound/UserNotFound
        req.accept(); 
        friends.save(req);
    }
}

There are other, similar, ways to organize the logic but the above should get the gears turning. Notice we didn't need to load any lists of friends! (and also arrived at a very terse, simple representation of our domain/rules)

The key concept here is to convert our rules into data (in this case our retryCount/sentAt/acceptedAt/expiresAt) that can then be used by our domain. This process is extensible to nearly any rule you can dream up. You want to check friends multiple layers deep? Project a isIndirectlyFriendsAlready field to our FriendRequest.

By representing our invariant with data we can then separate how/where we produce that data from how/where it is used. How could we add an expiry or retry counts to AcceptFriendRequest(User user1, User user2, List<User> user1Friends, List<User> user2Friends)? Are you going to enforce the same thing in SendFriendRequest? How? It becomes a mess.

Answer 2

Somewhat similar to @user3347715's answer, I would design a FriendRelationship aggregate root that contains exactly the data perimeter needed to enforce your invariant. So, load user IDs remote from user1 by up to 2 levels of friendship and check that user2 is not in there.

Note that it is more of a DDD purist approach than @user3347715's solution because the invariant logic will be in the domain layer instead of repository implementation or SQL query. But their answer might well be the more pragmatic one performance wise, depending on the amount of friend data to load at every friend request.

Another approach would be to make the operation eventually consistent with a deduplication background job that boils down direct+indirect friend relations to just an indirect one if the direct one is more recent.

This also questions the notion of friending in the context of your domain. Why do we feel the need to look past the first level of friends? Does it mean a level 2 friend is just as good as a direct friend, for some or all purposes? Could we then store a map of [direct or indirect] friends and get rid of the invariant, making the friending operation idempotent?

So, no silver bullet, only situational answers depending on the business domain, as often.