モデルが導く要件定義、文章が導くプログラミング
高校生の頃、私はシンセサイザーを購入し、ハードロックバンドのキーボーディストになることを夢見て演奏の練習をした。しかし、基礎もなく見よう見まねの独学による練習だったので、思うように上達しなかった。そこで、ふと思った。「自分が弾ける曲を作ればいいじゃん」あの頃からもう30年以上過ぎているが、このような発想は、今も私の基本的な行動原則である。現在は、ソフトウェア開発者として試行錯誤を重ね、そこで得たものを自分のソフトウェア開発戦略として実践している。この根底にあるものは、あのときと同じ「自分ができるようにすればいいじゃん」という行動原則である。このブログでは、私のソフトウェア開発戦略を、少しずつ紹介していきたいと考えている。
Rdra4 ddd
5. RDRAとドメインモデルの関係 RDRAは本来開発方法を選ばない Howは扱わない RDRA for DDDのスタンス 深い分析は開発側（ドメインの分析）に任せ、RDRAは整合のとれた要件を定義することに徹する RDRA 広く浅く分析 ドメイン分析 深く分析 ガツンと中心となる概念 をつかんで、育てていく RDRA Domain RDRAが外から攻め ドメインモデルが中核から攻める ドメインモデル RDRA 広く網を張り徐々に固めていく 5 6. RDRAで枠組みを決める 6 RDRAの役割 構成要素の洗い出し 深い分析のための構成要素を洗い出す スコープ決め 構成要素をつなげスコープを見極める 分類 コンテキストの見極め、業務分類の見極め 全体の枠組みを押さえながら進める RDRAで外枠を固めて安定したサイクル （タイムボックス）が回るようにする
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
