title: Golang - DTOs, Entities and Mapping
body: <p>I am new to Go having come from a C# background, and I am just plain confused about structure a Go application.</p>
  <p>Say I am building a REST API that will sit on top of a database. Also, say that, even after it is complete, this application could need to change somewhat frequently given the vicissitudes of the business, etc.</p>
  <p>In C#, with tools like Entity Framework and DTOs, I somewhat alleviate this problem by abstracting the database from the results given by the controllers. If I change the name of a bunch of fields in the database, I might have to change my database access logic. Still, hopefully, the DTOs that I map to my entities using AutoMapper can remain the same, so I don't break frontend functionality that relies on a given DTO structure.</p>
  <p>Should I replicate this structure with Go's structs? Something about such an approach seems wrong given that structs are just DTOs, and I will have quite a few DTO structs that are identical to the entity structs. I also have to setup logic to map entities to DTOs. This all just feels very unidiomatic somehow, and many of the examples I see on the web just serialize the database structs.</p>
  <p>In short, how do people avoid excessive coupling between their API and the database in Go, and how would they broadly go about separating out the different parts of the application?</p>
  <p>If it makes any difference, I am planning to use <code>sqlx</code> to marshal database results into structs which will mean more tags in addition to the JSON ones if I don't separate entities from DTOs.</p>