Software Architecture in Golang: Anti-Corruption Layer Pattern

[@MarioCarrion]

*Blog post* mariocarrion.com/2022/05/06/golang-software-architecture-anti-corruption-layer-pattern.html *Software Architecture and System Design in Go* kzbin.info/aero/PL7yAAGMOat_GCd12Lrv_evJ3Zhv1dl8B- *All playlists* kzbin.infoplaylists

[@BoosterShot1010]

Great content!, it would be greatly appreciated too if you could make a series on web development in go.

[@MarioCarrion]

Thanks. I'm working on creating a GraphQL series, I do have a REST one already but it's not as guided/step-by-step as the new series.

[@guhkunpatata3150]

i have some questions : 1. why use "country" as the input param ? 2. why make Fahrenheit and Kelvin code different when it will return the same thing ? func kelvin is more to the point than fahrenheit.

[@MarioCarrion]

I'm glad you left this comment because clearly the example needs a bit more of background, I added a README to the repo to give more context. 1. In summary we are building a system the returns temperature for different countries where our domain uses Celsius; we are re-using two existing third party APIs that provide values for some other countries we don't have access to. Therefore using "country" as the input for those APIs makes sense. 2. Both "kelvin" and "fahrenheit" packages represent third party party APIs that somebody else implemented already; we are reusing them but they have different domain model; sure they return the "same type" (float64) but the values returned are not compatible with our domain.

[@glenospace]

Your toy examples make no sense conceptually. Calculate(country), what are you on about. Please consider making your toys more natural when explaining concepts.

[@MarioCarrion]

You're totally right! Both packages ("fahrenheit" and "celcius") are not well written, that was the intention and that's why this pattern is useful in those cases.