要件定義・仕様化・実装の継ぎ目をなくす開発手法。 ビジネスロジックを軸に組み立てる。 値の種類（型）に注目してモジュール化するRead less

RDRA をやってて思うところ。 RDRAでは多くのダイアグラムが定義されていますが、これらのダイアグラムはきっと成果物（最終的に作るものの中核にあるものをこう呼んでみる）では無いです。多分ハマりどころ。 システムコンテキスト図も業務フロー図もユースケース複合図も、どれもRDRAのエディタとビューアでしかありません。中間成果物、もしくは補足資料的な位置付け。 じゃあ成果物が何かって言うと、各アイコンと関連線。詰まるところ全てのアイコンと関連線を持ったリポジトリそのものが成果物なんだと思います。 ダイアグラムを通してリポジトリを読み書きしている感覚。アイコンを見つけやすい、関連線を引きやすいダイアグラムを使ってアイコンを配置し、アイコン間に関連線を引く。その整合性を確認しやすいダイアグラムを使って、アイコンと関連線を検証する。各ダイアグラムはそのためのものでしか無い。 決して「ダイアグラムを

株式会社ビープラウドが主催するIT勉強会「BPStudy」。#151となる今回は、設計の代表格であるオブジェクト指向、モデリング、そして設計にフォーカスをあて、LT大会を開催しました。「ドメイン駆動設計に取り組んだ１５年でわかったこと 」に登壇したのは、ドメイン駆動設計に15年取り組み続けている増田亨氏。ビジネスルールと値オブジェクトと型という3つのキーワードを軸に、ドメイン駆動設計をソフトウェア開発に落とし込む方法論について語りました。講演資料はこちら ビジネス活動に起因する複雑さに立ち向かうドメイン駆動設計 増田亨氏（以下、増田）：よろしくお願いします。私は2006年ぐらいからドメイン駆動設計に実際に取り組んで、15年ぐらいやっているんですけど、今日はそれを私なりにわかったことというか、けっこう最近振り切ってこうやってますよという内容を、みなさんの参考になればと思って少しお話しします。

ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により