マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング

Merpay Advent Calendar 2019 の19日目は、Backendエンジニアチームの @toshinao がお送りします。 新しくマイクロサービスを立ち上げる機会があり、クリーンアーキテクチャをベースにしました。クリーンアーキテクチャはバックエンド・フロントエンド・アプリなど様々な場所で採用されています。ただ、確固たる方法というのは無く、みな試行錯誤しているのでは無いでしょうか。この記事では、クリーンアーキテクチャを取り入れる上で考えたことを紹介したいと思います。 マイクロサービスを作ったことがない人や、今までいくつか作ってきたけどより良い設計について考えている人の助けになれば幸いです。 はじめに メルペイのバックエンドは主にGoとGoogle Cloud Platform（GCP）で開発を行っていますが、各マイクロサービスをどう実装していくかは概ね各チームに委ねられてい

[honma200]

なんかめっちゃ色々小難しく書いてあるけど、肝心の依存について書かれてる感じがない・・・別にあの4重丸じゃなくていいんだって。肝心なのは何が何に依存するかじゃねぇの？そこからズレてる気がする

[turanukimaru]

ドメインオブジェクトがドメイン層外に流出するのを嫌がる人が多いが理由がさっぱりわからん。ついView用の関数をつけてしまったというのはpresenterが薄すぎるだけだ。あと汎用的な永続化はある…がGoには正直向いてない

[nilab]

「クリーンアーキテクチャはバックエンド・フロントエンド・アプリなど様々な場所で採用されています。ただ、確固たる方法というのは無く、みな試行錯誤しているのでは無いでしょうか」

[dorokei]

個人的にマイクロサービスは小さく作るイメージなので、あまりクリーンアーキテクチャとか採用しなくていいと思っている。金と人材余ってるからそれっぽいの作らきゃいけなくなってるイメージ。

[Phenomenon]

こういうの見るたび思うんだけどドメインロジックはドメインごとの役割の名前をつけるべきであって(domain)ってつけるの微妙じゃない？ (usecases)は複数のユースケースが入っているから仕方がないけど。

[msh5_h]

“過去にマイクロサービスを独自のレイヤー構成とレイヤー名で作成したところ、初見の人には分かりにくく、学習コストが高いものとなってしまいました。”そうそう、「決まりはないので何でもいいですよ」は evil

[hkr_I]

よむ

[PEEE]

構造体変換ボイラープレートが増えるのすごくつらそう

[ko-ya-ma]

the

[grandcolline]

めっちゃ勉強になった。