<< Responsibility Layers と関連するモデリング手法 | main | Domain-Driven Design を読み終えて >>

良いアーキテクトとは? (ドメイン駆動設計的アーキテクト論)

Domain-Driven Design(DDD)の17章に、ドメイン駆動設計的な、アーキテクトと、アーキテクチャ策定の要点(エッセンス)が6つ載っている。

だめなアーキテクト(個人/チーム)


ドメイン駆動設計に限らないと思うけど、まずは、だめなアーキテクトの特徴

× 最初に、がちがちにアーキテクチャを決め、プロジェクト全体の技術を制約
× アプリケーション開発をやっているチームに説明もしないし、声も聞かない
× ネットや本から拾ってきた、実証されていない、アーキテクチャを使いたがる

現場のことを何も考えず(知らず?)、自分の技術興味だけで調査し、サンドボックスで動けば、すべてOK、現場で問題が起きてもわれ関せず、...

こんな、アーキテクトやアーキテクチャチームが幅を利かすプロジェクトでは、良い仕事はできませんねえ。

こんなアーキテクトチームが良い


エバンスは、2つの成功パターンをあげている。

現場の技術リーダーが集まった非公式のアーキテクチャチーム


現場で、アプリケーションそのものを開発しているチームの中の、技術リーダーたちが、非公式に集まって、アーキテクチャの決め事や、改善を継続する。

公式には、概要的な決め事だけがあって、あとは、現場の技術リーダーたちが責任をもって、アーキテクチャを具体的に決め、プロジェクトを進めながら、アーキテクチャを改善し、発展させていく。

プロジェクト全体の目的や背景が、関係者で具体的に共有できていて、技術リーダーたちが、ビジネスの視点、プロジェクト管理の視点、システムのライフサイクルの視点などで、まともな議論ができる程度のマインド、経験、知識があることが、成功条件。

理想的なスーパー技術者、ということではなく、業務アプリケーションの開発プロジェクトで、まじめにリーダーがやっている人たちであれば、ほとんど、有資格者だと思う。

そういうメンバーが集まって、いろいろ話しをして、みんなが納得するものが、ベストのアーキテクチャ、だということ。

プロジェクト全体を仕切る、公式の技術チームがいない場合、自然発生的に、こういう非公式なアーキテクチャ策定チームがうまれることもある。

逆に、公式の技術チームがある場合は、この「現場技術リーダたちの非公式チーム」パターンは、いろいろ難しいだろうなあ。

公式のアーキテクチャチームが現場主義で取り組む


公式のアーキテクチャチームがうまくいくのは、

◎ アプリケーションの開発の現場に精通している
◎ プロジェクトの目的や背景。Context Map から、アーキテクチャを検討していく。
◎ 利害関係者(ビジネスパーソン、技術者、運用担当、...)と継続的にコミュニケーション
◎ 現場の声を元に、アーキテクチャを改善しつづける

という行動ができるチーム。

どんなアーキテクチャが望ましいかを、さまざまな利害関係者とのコミュニケーションを通して、模索しつづけるチーム、という感じかな。

アンチパターンのチームの裏返し。

現場主義のアーキテクト( Hands-on Architect ) が、良いアーキテクト。

アーキテクチャ策定の6つの要点


エバンスがあげている、6つの要点。

決定事項は、チーム全体に周知されること


アーキテクチャとか、大きな設計は、考え方であり、実体がない、といえば、ない存在。

アーキテクチャが実体を持つのは、現場の開発者がその考え方を理解し、日々の実装の中に、その考え方を、具体的に記述していくこと。

「周知する」と「強制する」は同じではない。

「強制」は、おそらく、相手が理解したり、納得することを軽視して、「ルール化」と「ルール違反チェック」という行動になる。

「周知する」というのは、相手が理解できるように努力し、納得して、実践してもらうことにこだわる行動になる。

「周知」するためには、相手が現場で困っていることを、いっしょに手を動かしながら、話しをするのがいちばん伝わりやすいと思う。

それを、時間のムダとか、非効率と思うなら、たぶん、ろくでもないアーキテクトの仲間入り。

決定の過程で現場の声を受けとめる


アーキテクチャは、アプリケーションの開発をしているチームが良い成果を出せるように支援するためにある。
自分の技術興味や、技術力の誇示のためにあるのではない。

主体は、常に、ドメインの概念を、ソフトウェアとして表現しようと奮闘しているチーム。
アーキテクチャチームは、そいういう現場でがんばっているアプリケーション開発チームの声にいつも耳をかたむけ、彼らの声を、アーキテクチャに反映し、アプリケーション開発者が喜んでくれることに、達成感を持つのが良いアーキテクト。

現場が喜ばないのは、選択した技術方式そのものに問題があるか、現場への周知の仕方に、大きな欠陥があるに違いない。

よいアーキテクチャは、アプリケーション開発チームに、喜ばれるもののはず。

エバンスは、「アプリケーション開発チーム」と「アーキテクチャチーム」で、技術者のローテーションを必ず行っていたチームを、うまいやり方の例としてあげている。

「計画」も発展させる


実装コードも、アーキテクチャも、マスタープランも、最初からベストの正解が、ぱっとできあがるものではない。

コードのレベルでは、リファクタリングとかのマインド、知識、経験を持った技術者やチームが増えている気はする。(楽観的すぎる?)

アーキテクチャやマスタープランになると、「最初に格闘して全体を決め、決めたら一切変更しない」という、「大きな前払い」かつ「思考停止」かつ「ソフトウェアと技術者の成長の抑圧」というのアンチパターンが、まだまだ多い気がする。

アーキテクチャや、マスタープランも、プロジェクトの中で、発展させていくのが、基本原則。

アーキテクチャチームに人材を集中させない


もっとも、技術力があるメンバー、マインド・知識・経験がしっかりしたメンバーは、アプリケーション開発チームに投入すべき。特に、コアドメインを担当しているチーム。

アーキテクチャチームは、ナンバー2に、まかせる。

他のメンバーも、アプリケーション開発チームに、まんべんなく、優秀な技術者を配置することをこころがける。

アーキテクチャチームは、技術の指導チームではなく、現場の優秀な技術リーダーたちの声を取りまとめ、実証し、絵やガイドやサンプルや部品として、その成果を現場に供給するためのチーム、という感じかな。

ドメイン駆動的には、アプリケーションのモデリング・設計・実装をするチームにこそ、第一人者を配置すべき。

アーキテクチャチームは、第一人者候補を育成する場にする。

minimalism と謙虚さ


アーキテクチャチームは、技術方式の決め事にあたって、「必要最小限」の決定をすること、他のチームの声に謙虚に耳を傾けることが必要。

これも、アンチパターンの裏返しですね。

「なんでもかんでも、決めたがって」「人の意見を聞かない」のが、最悪のアーキテクト(個人/チーム)ということです。

「オブジェクト」はスペシャリスト、「開発者」はジェネラリスト


大きな設計の最後の要点がこれ。

個人的には、これが一番気にっているし、心がけるべきだと思っている。

オブジェクト(ソフトウェアの部品)は、役割が単純明快な「スペシャリスト」であるべき。

いろいろな役割を兼任しているオブジェクトは、ろくでもない設計なんだ。

「開発者」は、正反対であるべき。

モデリング、設計、実装、データベース、メッセージング、インフラ、運用・監視、ビジネスパーソン、...

いろいろな顔(役割)を同時に持つべきだし、システム全体、プロジェクト全体で、どこでも、それなりの仕事ができる、ジェネラリストであるべき。

実際、「スペシャリスト」を自負する技術者は、アプリケーション開発の現場では、いつでも二流以下です。

得意分野をもつべきだし、磨くべき。

そして、その結果、一芸に秀でる主は、多芸に通じるに決まっている。

多芸ができない技術者は、一芸に秀でているわけがない。(つまり二流以下)

通信プロトコルが分かっているから、そのドメインのビジネスプロトコルの理解も早い、というのが、一流の技術者なんだと思う。

一流になれるかどうかは、能力というより、こころがけしだい。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< September 2018 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM