Conflict/leak of struct tags at the service layer

[diegobernardes]

What do you think about the multiple contexts that a struct can play in an application? For example, imagine that we have 3 layers at a given application: web, persistence, and service. We have a single entity called user that is used by all the layers, like in your example.

What happens when the user has different contexts on the other layers? For example, the persistence layer could require special struct tags for its own so we would be leaking an implementation detail to another layer that does not care about it. Same from the service to the web layer, what if we don't want to expose all the fields or change the tab name (JSON).

Because of these problems, usually I create a translation layer between these layers. It's more bureaucratic but gives me a lot of flexibility and control. What do you think about it?

[benbjohnson]

@diegobernardes I tend to start with a single representation that's shared by all layers and then add unexported structs within each layer as needed. Each layer communicates externally using the domain types but can utilize its own specialized types internally when it makes sense.

I do tend to leak out my JSON formatting in my domain types because it makes it easier than to have a full translation implementation.

[sleeping-barber]

@diegobernardes does this mean if a data type is changing in on layer you need to touch at least two places within your code? The data type itself and the translations out to other layers?

[diegobernardes]

Yes, but as @benbjohnson mentioned, this is only required in more advanced cases and it's totally optional if you don't mind leaking unnecessary information into other layers.