分かりやすいArchitectureって？

現会社の私のRoleは「Technical Architect」です。
私が目指している姿に【響き】が合っていて（Role名には）満足しています。
実際は入社時にちょっと訳ありで？このRoleになった経緯がありますが。
（例えばこのRoleレベルじゃないと、こちらの希望額を出すことは難しいとか。。。マネージャーとしてなら金額だせるけど、その経歴だとマネージメントできそうもないとか。。。あと金額だせそうなRoleはTechnical Architectくらいしかないとか。。。）

入社後（現在も）Role名ばかり先走って、（私にとっては）過大な期待とタスクをいただきながら ^_^; 日々奮闘しています。

現在携わっているプロダクトは、教科書にでも載ってるような「洗練されたオブジェクト指向」で書かれています。（私はそう感じた。）
「今のご時勢、当然だよ！」ってご指摘をいただきそうですが、ここまで美しく構成されているArchitectureには初めて出会いました。
しかも、.Netframeworkの機能（特性）を（骨の髄まで？）しっかりと利用しています。
具体例を書けなくてすみません。。。そんなの常識でしょ！って言われるのが怖くて。。。^_^;;

ただ。。。
これって本当に。。。

1. 理解しやすいArchitecture？
2. 生産性の高いArchitecture？
3. 品質を高く維持できる（不具合が出にくい）Architecture？
4. ソフトウェア自体の動作が速いArchitecture？

1と2は開発者（提供者）
3は開発者（提供者）と利用者（ユーザー）の両方
4は利用者（ユーザー）
のメリット／デメリットでしょうか。

新卒で入社した会社で「COBOL85」からスタートした「Static出身おじさん」固有の問題かもしれません。

ただ。。。
最近、（超遅ればせながら）「Ruby on Rails」の書籍を読みました。

その思想に
「これだよ！！」
って興奮しました。興奮した具体的な理由は別の機会に書けたらと思います。（先送り。。。）

それもあって。。。
「洗練された（格好いい）オブジェクト指向」＝「理想的なソフトウェアの姿」
なのでしょうか？

「オブジェクト指向」は、当然ながら「オブジェクト」を中心の構造です。
「どうも人間に優しくないなぁ」
と感じるのは、私だけでしょうか？

いずれにしても現状のプロダクトはそんなArchitectureなのですから、これにもしっかり順応するしかないですね。
「Technical Architect」なんですから ^_^;;