Why are the update/filters structs in root package?

[mroobert]

Hy Ben,

Thanks for you ideas! Awesome work!

I've seen that you use UserUpdate and DialUpdate for the update operations. They are defined in the root package. Also the filters structs are present in the root package.

How are they considered domain types? It looks to me they play a role of DTOs more than domain stuff.

[benbjohnson]

How are they considered domain types? It looks to me they play a role of DTOs more than domain stuff.

Good question. They're used from any package that wants to implement functions like FindUsers(). Since it's a common type that's shared by dependency packages, it needs to live in the root so they can all share the same interface.

They can be used as a DTO, however, you could have protocol-specific implementations within the subpackages if you wanted to transfer a "protobuf" object, for example. Does that help?

[mroobert]

Thanks for the reply!

Yes, it makes sense. But...

• If we look at the DialFilter, we can see that it contains Offset and Limit. These will restrict the subset of results. All is good here.

• If you switch the database with something like firestore, the pagination logic is a bit different. This means that you need something different than Offset & Limit on the DialFilter. Doesn't that mean we leak some details from our storage implementation into the domain package?

Can be this a good way of thinking about these 2 bullet points?

Another way to think about this is to imagine that there are different service implementations, an entity can be stored anywhere, for example, in Postgres, Firestore, Kafka, memory, Redis, JSON file, remote API.
We need to keep in mind semantics that storage of choice provides: getting a list of entities from Kafka and Postgres are hard to abstract (streaming vs quering). Moreover, if we do so, we might create unnecessary constraints for ourselves. In reality, it is very unlikely that a project will change storages often, since we've chosen them for a reason (the choice of the storage is influenced by a problem we're solving, its constraints and guarantees we need).

Most likely we've already chosen the storages in advance, so we need to make sure we don't fight with interfaces we defined in our domain model.

[benbjohnson]

Yeah, that's a good way to think of those points.

It does leak implementation details into the domain package and if you have multiple backends with different pagination systems then you'll have to figure out a system to make that work. Those details eventually leak into higher layers too like http & the UI since those need to handle the pagination system of the underlying database. I'm not sure of a better way to do it without making it overly complicated.