go design - correct way to pass data/behaviour around, in large codebase used by multiple teams

I managed to convince a bunch of colleagues to try go for a new system. None of us is experienced in go and while this is a 'because we can' project and we have some budget to burn I would like to see go succeeding within the company in the long term, so some planning is needed beforehand..

I'm looking for the 'proper go way' of structuring a program when it comes to passing data and behaviour between distinct 'units'. More specifically the program will be comprised of multiple packages, each of which performs some data collection and analysis and stores the results in a fairly large struct (one struct/one type per package mostly). We want to define 'contracts' with other teams that create other packages that are concerned with parsing that data and either presenting it (through http web rpc for example) or performing further analysis etc

I want to avoid:

• duplication of code (i.e. I don't want to have a separate parser for each type, I expect a lot of overlapping functionality between the produced types)

I want to achieve:

• keeping responsibilities separate as much as possible (i.e. parsing the data belongs in a parser package, not in the same package as the one that scans the system for data, as maintenance is then likely to become problematic, same with presenting the data, I don't want every parser package to bundle it's own router etc)

Essentially it boils down to:

• what to use to pass these 'objects' around - I can't just use the equivalent of map[string]object for example (or can I?), a single type struct with bazillions of fields followed by if/else in the code doesn't seem to make too much sense either and marshalling/unmarshalling to json feels too 'heavyweight'. I thought about getters/setters on an interface but that is probably too java-like and not what a proper gopher would do
• how to structure the program in order to achieve as little duplication as possible, end up with a recommended design based on go principles etc. I took some time to go through the code in some popular "devops" projects and it seems it's a right mess at the moment :)

As an example, if I was using an object oriented language I would be able to 'wrap' my data in plain objects with getters/setters that would present a uniform interface regardless of the underlying data type, then on a higher level define interfaces with a basic shared set of messages, have classes implement these behaviours, use inheritance to minimize code duplication between classes of the same base type etc.