読者です 読者をやめる 読者になる 読者になる

GeekFactory

int128.hatenablog.com

SIerにおける多層アーキテクチャパターンの一考察

SIer

ソフトウェアアーキテクチャやシステムアーキテクチャにパターンがあるように、SIer多重下請構造多層アーキテクチャにもパターンがあると考えられます。本稿では、プログラマ35歳定年説等を考察するにあたって基礎となるパターンを提案します。

筆者が提案するパターンの一つを下図に示します。

お客様サイド
スポンサーです。お客様サイドは業態によりアーキテクチャが大きく異なり、しばしば仲間割れがあったり、下位レイヤをバラバラに統制することもあります。
営業
ユースケースの起点となるレイヤです*1トランザクションの開始や終了に重要な役割を果たしますが、意外と社内政治力を持ち合わせていないこともあります。ただの見積屋にならないよう注意が必要です。
アプリ屋
アーキテクチャを構成する最大勢力です。といっても本レイヤにロジックはほとんど含まれていないため、下位レイヤへの丸投げ委譲によりトランザクションを実行します。世間ではスーツと呼ばれています。
インフラ屋
堅牢なアーキテクチャを実現する要となるレイヤですが、一方でしばしばリファクタリングを阻害する要因にもなります。特に頭の固いdeprecatedなメソッドが多用されている場合はコストが大きく膨れあがります。
ソリューション屋
様々なユーティリティ群から構成されます。上位レイヤとの関係は多岐に渡ります。世の中のテクノロジに触れる機会が多いため脱藩しやすいと考えられますが、一方でただの代理店プロキシになっていることも多いので注意が必要です。
火消し
必要な時に生成されるワーカーです。ガベージコレクタにより回収され、別の案件に手配されます。優秀な人材が埋もれてしまう危険性があります。
n次請け
上位レイヤからのトランザクションを受け付けて処理します。レイヤ間のインタフェースは暗黙に定義されていることがほとんどで、しばしば無茶ぶり適切な例外処理が必要となります。


本エントリはただのジョークです。これを読んで気分を害された方はごめんなさいです。

*1:なぜユースケースの起点がお客様サイドじゃないかって?それは「持ち帰り検討します」が起点だから。