認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏

自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える

[p1ass]

こういう縦の切り方に関する考え方は参考になる

[noseld]

良い。金払うから具体例もみたい。特に認可周り。

[nicht-sein]

認可の分離ってえらく難しい印象なんだけどどんなんがベストなんじゃろほい。認可の時点で内部構造にがっちり食い込んでいるしなぁ

[uzulla]

すごくわかるけど、分散すると障害時のトレースと適切なUXを保つユーザーへの掲示が結構難しい（まともなAPIのまともなマネージドをつかえというのは全くその通り）

[SWIMATH2]

わかるけど具体的にどうやるのか見たい

[kyuns]

実際に分離して良かった

[hyirm]

すごくよく分かる話。この辺は分離しておきたい（けど中々そうなっているケースは経験上少ない・・・）

[kagerou_ts]

わかりみ…

[miyasakura]

これはすごくわかる

[magnoliak]

このエントリの考え方が良い、という話をしました

[nabinno]

FE側にisAdminフラグがあった時点でいろいろ考えてしまう...

[n_231]

“キャンペーンの種類が増えるたびにユーザーリストを作るのは現実的ではない。” せやろか？(遠い目)

[YaSuYuKi]

認証、認可、課金の3つは、そもそも、コアドメインの要求と直結した特別な目的がない限り、自力で実装すべきでない。システムを超えた共通性が高く、セキュリティ要求が厳しく、必要最小限の規模が大きすぎる

[otihateten3510]

勝てるって「しか勝たん」みたいな話？

[redredstar]

昔、認証、認可、課金のみできるサービス作って死ぬ思いしたな。。。

[masatomo-m]

初期投資のコスト（エンジニア工数及び熟練度、サービス使用料）がどれくらい積めるかにもよるけど、成長する前提でやるなら最初から分離するに越したことはないよなあ

[Chisei]

なんとなくわかるけどまだわかりきっていない。何回か読みたい。

[akulog]

"サービス成長に伴ってお金に余裕がでてきたときにマーケティング系の施策をうつことが多くなる。 その時点で分離してないと「そんな要件みたせねーよ」といった機能を求められる。"

[circled]

少なくとも課金はクレカ情報を自分ところで抱えるなんて怖くて出来ないからstripeとかPayPal使いたいよね。もしくはApp Store経由とか。

[paradisemaker]

ああ、確かにこのへんの考え方は今の基本セオリーになってると思う

[toro-chan]

勝てる要素がなく、負け切ってるような気がする。分離出来た気になってるだけ。後から見ると、「最初期課金マン」って定義をした時点で完全に負けてる。その5年後、その定義自体を忘れ去ってるのは間違いない

[rryu]

認可というか、金銭が絡む権限や特典は生臭い事情によりカオスになりやすいので、最初に混沌を受け入れられる土台を作っておかないと混沌に飲み込まれるという。

[toritori0318]

"認証、認可、課金とコアドメインってのはなんの疑いもなく1000%分離すべきものである"

[akiramaz]

ちけん

[cubed-l]

認証と認可は別だしね

[machataka]

言いたい事はわかるけど、脳死の使い方が不適切。

[masa8aurum]

「認証」「認可」「課金」はコアドメインと分離すべきらしい。

[yujiorama]

アスペクト指向…

[lesamoureuses]

なるほど “分離されていれば「初回課金マン」みたいな権限用意して権限チェックのときに考慮するだけで済む。 ”