さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

[riveroka]

ソフトウェアの寿命よりビジネスの寿命のが極端に短かったでござる

[Tomato-360]

わからないこともないけど、アーキテクチャは事業を成功に導くというより事業を壊さないようにするというイメージがある

[baronhorse]

ああ。売り上げ立って昇級して現場離れて後任に恨まれるやつね。

[ledsun]

「Clean Architecture」って本に書かれている内容（アーキテクチャのパターンはあってもそれが俺たちのアプリケーションにそのまま使えることはなく、成長に合わせて自分らで考えるしかなくね？）そのものでは？

[oinume]

"売り上げは全てを癒すけど、アーキテクチャは全ては癒してくれないんですよ。" 名言だ

[j5ik2o]

ビジネスを成功に導けないのは確かだけど、アーキテクチャによってはビジネスを失敗に追い込むことはできる。特に非機能要件の影響は大きい。頻繁にダウンとか応答性が悪いと競合サービスに乗り換えられてしまう

[manimoto]

「チームメンバーの大半がどの書き方に手慣れてるか」もWeb界隈は人の出入りが多いので、極論Railsで言うと標準+著名gemが生やすディレクトリ以外は作らない方が新メンバーの学習コストは抑えられるのではとか思う。

[otihateten3510]

何でも良いじゃなくて、一番オーソドックスなやつにするべき。特別なアーキテクチャは必要になるチームなんて滅多にないって皆気づいて欲しい。　もちろん同じ組織で10年一緒に開発するなら極めてもいいけどさ

[raydive]

理想としては複雑度は関係なくて、ルールをきめて守れる人がチームに入れるようにするだけなのではという気がしないでもない。

[mitsugi-bb]

Keep it short and simple.　につきる。そんでsimpleに保つことは難しい。DDDは山奥で修行して仏様への道を歩むイメージ。それって、ある意味パラダイムシフトに弱いよね。南無阿弥陀仏で良いじゃん。的な・・・ちゃうか。

[luccafort]

言わんとするところはわからなくはないと思ってるんだけどビジネスがブーストしようというタイミングでアーキテクチャが足かせになることはままあると思っててそういうときのためのアーキテクチャ論かなぁと思ってる

[boomerangj]

アジャイルとかスクラムも同じだと思うので気づいてほしい。要は使う人次第という身も蓋もない話。

[ku_marin]

“売り上げがまず立つことや、チームのリテラシーや人数がスケールすることが大前提”

[udzura]

今更読んだんですが、「コードを読むときの思考の流れが決定的に違う」これだよあなあと思った

[shirakiya]

"売り上げは全てを癒すけど、アーキテクチャは全ては癒してくれないんですよ。"

[rexy]

アーキテクチャパターンとアーキテクチャそのもののがゴッチャになってない？

[sigwyg]

個人的には「楽しく議論できる」or「意思決定がスムーズな」チームならアリ、という方針。強力なリーダーか助言者が居て、うまく回るなら有効。頻繁に対立が起こるなら害。やっぱ人だねー

[nyamadori]

“みんなでスクラムを組んで正解を模索し続けないと、少数の興味ある人間が開発チーム全体の障害点になりうるわけですね”

[pakkunflower]

Go言語ならテストも考えると垂直分割の方が良さそうだし、言語によっても戦い方は変わりそう。郷（Go）に入っては郷（Go）に従えということなのかもしれない。

[glass-_-onion]

クリーンアーキテクチャの話題でユニットテストについて語られずレイヤーの話に終始している点が非常に残念。アーキテクチャがグタグタだと事業のスピードに追いつけず負債が溜まって行くので常に改善が必要

[RabbitBit]

技術寄り・ビジネス寄りの対比で、ビジネス寄りの人物をスーツと呼ぶ風習を聞いた事があるが、だとすれば｢スーツを着込んだ｣方の記事だと思う。私も、慣れないスーツを着込むようになった。

[arrowKato]

DDDやクリーンアーキテクチャで、みんなでスクラムを組んで正解を模索し続ける。上記を職場での開発の日常として紹介したら、結構なエンジニアホイホイ。それがチーム内の認識合わせコストにつながるのは結構ショック

[aike]

わかる。自分はアーキテクチャ推進派かつドメインというまとまりでコードを読む派なのでたまに感じるもやもや感をうまく言語化された感じ。複雑なシステムとビジネスをそれぞれ構造的に表現するバランス。

[michiomochi]

わかる

[uva]

「売り上げは全てを癒すけど、アーキテクチャは全ては癒してくれない」

[mayumayu_nimolove]

地殻、マントル、コア

[hamamuratakuo]

"「アーキテクチャ」と「フレームワーク」は違うんですよ。" 　ドメインを表現するときの親和性＝フラット（単純）→命令型、レイヤー（複雑）→宣言型。適材適所で使い分ければOK？

[chintaro3]

インフラはアーキテクチャがしっかりしてた方が良いけど、表層のアプリならそんなもんやろな。

[endout]

“売り上げは全てを癒すけど、アーキテクチャは全ては癒してくれないんですよ。”

[syunnchang]

良いアーキテクチャでも売れるとは限らない

[mamacake]

サービス開発に割けるリソース量と、売上のバランス次第

[lucifer_af]

「売り上げは全てを癒すけど、アーキテクチャは全ては癒してくれないんですよ」

[yusuke-k]

アーキテクチャは事業に成功をもたらさない。売上はすべてを癒すがアーキテクチャに癒されることは限られている。 こういうのもコンウェイの法則につながる話で、事業、アーキテクチャ、チームはすべて地続き

[tanishiking24]

“売り上げは全てを癒す” これ

[EngineerYtr]

“アーキテクチャは事業を成功に導くか 導かないと思うんですよ。”← 共感する。ゴールと最低限のロードマップが共通認識としてあれば不要かも。巻き込むための作業は非生産的だしね。

[ene0kcal]

弊社（仮）のアーキテクチャと重複コードやレイヤ無視した実装の悪さ、年号をDB管理してないせいで年号追加時にBP呼んで1000万弱かけて追加、整理できていない場当たりの不具合修正をみてもそう思えるか大疑問です。

[sezemi]

テストが書きやすいからって本に書いてあったのは、あれはなんだ。。

[mkusunok]

終わりなき茶飲み話でしかないんだけど、チームにどう浸透させるかとトレードオフの話に終始してるところがネットっぽい。ここに時間軸の設計負債と性能・要員のスケーラビリティを掛け合わせるとカオスになるわな

[msykt]

これから作っていくサービスを考えて、どこにもリスクが無いと思えるなら、そんなにアーキテクチャに気を使う必要はない。リスクが無いと判断した箇所のアーキ議論には付き合わない。よしなにやってもらうのみ