Layered architecture Go API implementation Jumpei Takiyasu @juntaki M3, Inc.

= &Me{ Name: "Jumpei Takiyasu", Company: "M3, Inc.", Github: "juntaki", Twitter: "juntaki", Web: "https://juntaki.com", } recent := &Work{ "goo.glも終わるしGoとGAEで短縮URLサービスをつくろう", // https://s.juntaki.com/bAd "OK,Google Alexaに今日のニュースを聞いておいて", // https://s.juntaki.com/Q6T "Configurable Slack bot firestarterのつかいかた", // https://s.juntaki.com/sVd } About me

juntaki/firestarter ● Just-start bot ● Simple web UI for configuration ● Use in combination with various webhook such as IFTTT, Jenkins ● Available for @everyone ● Please try using this!! firestarter is made for simple working example of Layered architecture in Go. https://s.juntaki.com/sVd

Architecture of firestarter

System-wide architecture firestarter(bot) Real Time Messaging Interactive messages firestarter(UI) config.json Internal API POST The internet Company Internal AWS Lambda Amazon SQS Amazon API Gateway

firestarter(bot) Real Time Messaging Interactive messages firestarter(UI) config.json Internal API POST The internet AWS Lambda Amazon SQS Amazon API Gateway Architecture to be described Company Internal

Overview - Layered architecture & Data Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Data Layer API input / output (xml, json, protobuf, ...) Persistent storage format (DB schema, File format, ...) On memory structure Controller (IDL definition) Deserialized API input / output UI What end user want to do Translator Translator Are there too many layers?

Dependency Layer Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Controller (IDL definition) UI What end user want to do The upper side of the figure is the High-level modules. There are more components in higher-level modules, which may change frequently. Flow of control Modules example

Model-View-Controller like pattern point of view Layer Controller View Model MVC POV Modules should rely on the layer to less frequently change. High-level changes make just local impacts. However, If there is a change in the Low-level module, the impact propagates extensively. Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Controller (IDL definition) UI What end user want to do Modules example

Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Controller (IDL definition) UI What end user want to do Dependency inversion principle point of view Layer Logic Presentation Data DIP POV Abstructions Abstructions High-level modules should not depend on low-level modules. ...means, reducing dependence to modules with many dependencies. High-level changes affect low levels, but the propagation range of change is measurable. Modules example

No silver bullet The way to implementation is depending on the purpose of software. ● For speed at initial stage, MVC like arch. ● For maintainability, DIP approach. You should consider some benefit of original module may be lost by excessive abstraction. (e.g. performance) Gopher may prefer robust DIP approach, layered architecture. ● Easy to test by mocking ● Interfaces implicitly decide each modules responsibility

Dependency injection (DI) Layer DI is just strategy pattern. Modules to be injected is the source of inverted dependency. Where to inject it from? ● DI container ● main() ● (or another choice) Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Controller (IDL definition) UI What end user want to do

Directory structure Directory structure Layer Contents ├── admin UI Vue.js ├── proto Controller protocol buffers definition generated code (twitchtv/twirp) ├── application Application API Server impl ├── domain Domain Domain model Validator (go-playground/validator) Repository interface ├── infrastructure Infrastructure Repository impl: JSON serialization └── main.go - DI and load global settings Think framework (go-chi/chi) https://github.com/juntaki/firestarter

DI at main() Inject Infrastructure dependency Inject Application dependency Application depends on domain Infrastructure implements domain’s interface https://github.com/juntaki/firestarter/blob/master/main.go

Data translation Data API input / output (xml, json, protobuf, ...) Persistent storage format (DB schema, File format, ...) On memory structure Deserialized API input / output Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Translator Translator Translating is troublesome, but it is necessary for layer decoupling. The structure of each layer may be approximately the same at the initial stage. Generated code by protobuf Anticorruption, or..

Data mapper

Stamp coupling, Data coupling? Command, Query? Persistent storage format (DB schema, File format, ...) On memory structure Deserialized API input / output Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Translator Translator Command / Query Instead of increasing complexity, it will be more robust architecture.

Wrap up ● Layered architecture is complex but robust design. ● Data translation is important for layer decounpling. ● No silver bullet Go API implementation is not easy but simple. It’s ideal for implementing complex architecture.

References Challenge to Advanced API Architecture in Go by Seiji Takahashi https://speakerdeck.com/timakin/challenge-to-advanced-api-architecture-in-go GoにおけるDI http://inukirom.hatenablog.com/entry/di-in-go The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license.