How would you handle service/domain relationship?

[anthonycorbacho]

Hi @benbjohnson,
first of all, I wanted to thank you for this very interesting series of project and blogs, it has been very inspiring!

My question is about what will be the best way to handle the case when the service might need several other services to produce its data? for instance, let's say I have an application that manages Location (like google place or foursquare location) and a user can follow this location or search for a location.

I can see something like this in my root

package myapp

type Location struct {} // represent a location with ID, name, address etc

type LocationRepository interface { ...} // Database CRUD for location

type LocationSearch interface { ... } //  Search a place by using google map API or foursquare API

type follower struct {} user that follow a location (user ID+location ID and meta)

type FollowerRepository interface { ...} // Database CRUD for folloer

type User struct {} // application user ID, name etc

but then the question is, how can I model a service that will give my Give me a space with all followers or list user place?

should I create a new struct in the root that combines repository interfaces?

type LocationFollower struct {
  Location
  Follower []*User
}

type LocationFollowerService struct {
 location LocationRepository
 follower FollowerRepository
}

func (lfs *LocationFollower) fetchLocation(ctx context.Context, locationID string) (LocationFollower, err) {...}

Or should I do something different?
Thank you.

[benbjohnson]

Hi @anthonycorbacho. Yes, I'd have a struct in the root that combines both the LocationRepository & the FollowerRepository. The only things I'd change about your implementation are: 1) rename fetchLocation() to FetchLocation() so it's exported, and 2) maybe find a different name for LocationFollower. I'm not sure what exactly though. It doesn't feel like a name I'd use to describe it IRL.

[anthonycorbacho]

@benbjohnson thanks for your prompt and clear explanation!

Another question I have for you is about the pattern CQRS (Command and Query Responsibility Segregation)?
I found that this pattern increases the application complexity and I wanted to know if you have good practice in terms of how to manage database interaction.