変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita

この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

[mint6626]

個人的な体験でいくと、5000万円くらいまでのプロジェクトだと変更に強いアーキテクチャが活躍する前にリプレイスされてしまう気がする

[kazoo_net14]

SIだとこのレベルの話より、DB設計が全てなきがするな。 まあいろんな考えあるやろーけど

[rgfx]

あとは適切なデータモデルも

[htnmiki]

IT業界0年の俺が思うに変更への強さはアーキテクチャどうでもよくて変更すべき時期に変更を決断実行できる人がいることじゃないですかね（どうでもいいは言い過ぎ）

[satohu20xx]

僕の感覚と似ている。各層の名前が変わるだけで、こんな感じの設計に落ち着くことが多いと思う

[atsushifx]

本当ならソフトウェア工学でのソフトウェア品質をみるべき。モジュール(部品)の一つを変更／入れ替えてもほかのモジュールに影響がないなら変更に強いし、やりやすい

[HHR]

良記事。たまに煽るのも程よい清涼感を生んでいる。“Qiitaを読んでいるような意識高い系の人はそんなことないのかも知れないが”

[fa11enprince]

わかりやすい。Spring Boot + JSのFrontend FWをデフォルトで適用したらだいたいこうなる。Railsの場合はサービス層相当がやりにくいが皆どうしてんだろう。

[at_grandpa]

かなり同意。最後の「どこまで適用するかの見極め」がとても重要だと思う。こういうのは使いたがってしまうけど、今のフェーズで本当にそこまで必要なんだっけ？という部分。

[ninneko]

業界19年目とか内容に関係ないところでマウンティングとるやつはろくでもないやつってわかんだね

[grandcolline]

・適切なモジュール分割 ・依存関係を一方向にする ・テストコード が大事らしい。

[zu2]

サービスの寿命って想定外に長くなったりすることがあるので、最初で注意するにしくはない。問い合わせを受けて「えー、まだアレ使ってるんですか」って思ったこと多々ある

[takatoshiono]

いい。同意

[honma200]

モデルってDBに対応したもの？ビジネスロジックはサービスで吸収する？んんん？私にはしっくりこない

[masaru_b_cl]

ここだけでもう勘弁してほしい > "Model が DB に対応していて"

[moronbee]

これは良いテキスト（と先生）。自分も同じ感覚 // Webアプリ層の設計の話→その後の生存コストに効いてくる。ただ、ビジネスが生み出す利益orコスト効果とは別の話（ここ注意）

[kabacsharp]

委譲アダプタかな？　“ここでは利用の依存関係を解消するために（王道とも言われる）インターフェースを抽出する方法を説明する。”

[yarumato]

“経験上ゆずれない3項目：1)適切なモジュール分割（MVC以外にService（業務ロジック）を導入。入出力を別々の新しいModelに定義）　2)依存関係を一方向にする　3)テストコード。1→2→3の順に。2まででも効果ある”

[taguch1]

MVCって久しぶりに聞いた気がする。

[iwasiman]

図もわかりやすくて良記事。だいたい同じような肌感覚ですね。伝統的なMVC+Service層の構造は自分もFW自作の時にやりました。

[yamadadadada2]

これはほぼクリーンアーキテクチャですな

[odakaho]

“Qiitaを読んでいるような意識高い系の人”

[at_yasu]

だいたい分かる。個人的には、ソフトは更新できるから、更新が難しいDB設計が重視だなぁ…

[tettekete37564]

過渡期的まとめとして良さげ / DIやクリーンアーキテクチャとテストの関係を理解していれば大体同じ答えになると思う

[houyhnhm]

変更に強い→構築中の設計変更に、くらいでしょう。

[otihateten3510]

うーん、こんなに複雑にする必要あるのかな。／依存方向１方向になってるこれ？？？

[kibitaki]

昔に比べて自前クラスをきれいに描ける人減ったなぁ。テストパターンについてはもう少し思うところあるものの、基本すっと入る内容なのでとてもいいと思います。／19年に噛みついてる人ら、損だよ。

[sononon]

Webディレクターとしては更新しやすいシステムを維持するリソースを空けてあげたいものの、そのサービスが、果たしていつまで生きているのかというジレンマにいつも悩みます。

[shibadoog]

これ、じっくり読もう。

[otherworld]

個人的にこの辺はHexagonal Architecture(Ports&Adapter)の考え方でしっくりきてる。

[gui1]

大手金融機関がVB6で構築したクラサバシステムをマイクロソフトを恫喝して延長サポートさせてたシステム、まじでメンテ楽だったわ。社内システムにしか使えないけど(´・ω・｀)

[gomayumax]

“サービスの入力と出力を同一のモデルに統合してしまわないとこ。 本当に同じ意味のデータならそれで構わないが、意味として異なるのであれば別々のモデルとして定義するべきだ。”

[natu3kan]

損をして得を取る考え＞テストコードを書くこと自体にコストがかかるが、長い目で見ると全体的なコストは下がる

[nyop]

アプリレイヤはわかる。だがそれ以前にモデル(データ構造)のレイヤがきれいになってないとなんだよねー。