-
Tanaka9230
- 2167
- 3
- 1
- 0
-
- いいね！0
増田 亨
@masuda220
要件定義やソフトウェア設計の重要性が改めて認識されるようになってきた。 昔のやり方の復活ではなく、進化した考え方とやり方で。 RDRA、ドメイン駆動設計、オブジェクト指向プログラミング twitter.com/haru860/status…
2019-09-25 07:54:12
佐藤治夫
@haru860
昨日のBPStudy#145〜〜進化する要件定義(RDRA meets DDD)の、LT資料(エンジニアリングの復権)です。 #bpstudy speakerdeck.com/haru860/enzini…
2019-09-25 07:29:48
増田 亨
@masuda220
2000年代前半のオブジェクト指向分析設計のブームの頃は、今から見れば、データモデリングのエンティティと、トランザクションスクリプトの自然言語の記述としてのユースケースという使われ方が多かった。 つまり、オブジェクト指向といいながら手続き的な設計スタイルの延長だった。
2019-09-25 08:15:21
増田 亨
@masuda220
2020年代は、原点回帰。オブジェクト指向プログラミングの考え方とやり方の基本に立ち返ることがたいせつ。 プログラミングは設計そのものであり、設計と分析も一体である。 オブジェクト指向のモジュール構造は型(値の種類)の分類構造である。 クラスは型の実装をカプセル化する手段である。
2019-09-25 08:15:21
加藤潤一(かとじゅん)
@j5ik2o
@kyon_mm @masaru_b_cl そうです。それは別々にするのですが段階があると思ってます。物理制約を設けないで要望をヒアリングしてそれらを要求として検討し物理制約を踏まえて要件化(すべての要望が要件になるわけでない)するという要求分析の段階があるので、最終的には物理制約が加味されないと合理的ではない印象です。
2019-09-25 08:33:25
増田 亨
@masuda220
神崎さんのRDRAの本質的な価値はシステムの利用者の関心事を、そのまま可視化することにあると思う。 逆にいうと、システムを構築するためのインプットとしては、利用者が気にしていない詳細や、意識できていない背後の構造は見えてこない。 そこを発掘し具体化するのが開発者の腕の見せどころ。
2019-09-25 09:28:53
増田 亨
@masuda220
要件定義とソフトウェア仕様の定義は同じではない、ということ。 要件定義は、あくまでも利用者の要求や期待の言語化であり、ソフトウェアの詳細の言語化ではない。 設計はソフトウェアの詳細の言語化である。基本の表現手段はプログラミング言語。
2019-09-25 09:43:40
増田 亨
@masuda220
利用者がほとんど意識していない詳細をプログラミング言語で表現するときに、可能な限り業務活動に登場する言葉を使う。 あるいは、詳細を表現する言葉が業務に自然に入り込み溶け込める言葉を探す。 ドメイン駆動設計のユビキタス言語づくりは、そういうプログラミング側からの言葉づくりが本質。
2019-09-25 09:43:40
加藤潤一(かとじゅん)
@j5ik2o
ですね。RDRAとDDDを組み合わせてやっていると必然的に意識するようなったなぁ。 twitter.com/masuda220/stat…
2019-09-25 09:46:09
増田 亨
@masuda220
@j5ik2o 私もドメイン駆動設計に取り組む中で、RDRAに出会い、RDRAを学び、現場で使って、そういう知見にたどり着きました。
2019-09-25 09:50:02
増田 亨
@masuda220
RDRAを使って、利用者の関心事を可視化する。 全体の関心事から、中核の関心事とそうでない関心事を分別しながら、中核の関心事を対象にICONIXで、詳細に入り込んでみる。 ICONIXのユースケース記述やロバストネス分析をしながら、中核の関心事に登場する値の種類（＝型）を発見する。
2019-09-25 10:10:50
増田 亨
@masuda220
型の名前、値の範囲や値の集合、その値を使った操作に注目しながら、クラスとして実装してみる。 計算が主体の値オブジェクト、条件分岐に関係する値を整理した区分オブジェクト、それらのまとめて操作するためのコレクションオブジェクトや集約オブジェクト。
2019-09-25 10:10:50
増田 亨
@masuda220
そういうドメインオブジェクトをそろえながら、関連するデータを記録し、参照するためのデータベースを設計していく。 外部とのデータ形式との変換が重要であれば、そちらも部品を準備。 そうやって、部品がそろってきたら、ユースケース記述をアプリケーションサービスとして実装してみる。
2019-09-25 10:10:51
増田 亨
@masuda220
実装の結果を、RDRAで可視化し、俯瞰した関心事の体系と突き合わせてみてり、ICONIXのロバストネス分析と照らし合わせてみる。 オブジェクトの設計の不備が見つかることもあれば、全体像やロバストネス分析に歪みや不整合が見つかることもある。
2019-09-25 10:10:51
増田 亨
@masuda220
そうやって、全体と部分、要求と実装をいったりきたりしながら、全体を整え成長させていく。 自分のアプリケーションの開発スタイルを言語化すると、こういう感じになる。
2019-09-25 10:10:51
杉本啓
@sugimoto_kei
↓エンジニアリング重視と技術・実装重視の間で揺れていること自体がコの業界の問題のような気がせんでもないですね。ドメインはどこに行った？ドメインに没入しよう。
2019-09-25 17:38:40
杉本啓
@sugimoto_kei
「費用の振替」というユースケースがあったとする。なぜ費用を振り替えるのかを語り出すと、それをおかずにして、ごはんなら、たぶんどんぶり三杯はいける。でもそうした理解を踏まえなければ、費用振替の必要性はわからないし、その代替案も議論できない。そんなの、方法論とかでなんとかできるのか？
2019-09-25 17:42:50
杉本啓
@sugimoto_kei
汎用的方法論やら分析技法やらだけで、ドメインの問題を理解し分析し解決策を設計できるという考えがいかにゴーマンか、エンジニアのみなさんは、あんまり、気付いていない。
2019-09-25 17:45:17
杉本啓
@sugimoto_kei
@akimicyu まあ、DDDは、ドメインを重視すべき、というメッセージを、ドメインに依存しない汎用的な語り口で伝えようとしているので、色んな解釈が生まれるのだと思います。こういうアプローチは、結局、何ももたらさないのかもしれません。
2019-09-25 18:14:11
杉本啓
@sugimoto_kei
先人の仕事を尊重することは、先人の言う通りにやることとは違う。ドメインに没入せよというのは、ドメインの慣習を受け入れろという意味ではない。僕らは、新しい方法と慣習を生み出す。それが設計だ。その際に、古い思想と慣例を出来る限り素直に理解し、その上でそこから離陸すべきだということ。
2019-09-25 18:16:01
杉本啓
@sugimoto_kei
業務要件：人の作業＋コンピュータの処理からなる「業務システム」がなさねばならないこと。 ソフトウェア要件：コンピュータのソフトウェアシステムがなさねばならないこと。 システム要件：文脈に依存して上記のいずれかを指す、テケトーな用語。 視点や要求元が違うのではなくて、単に対象が違う。
2019-09-25 18:55:39
杉本啓
@sugimoto_kei
こんな風に定義してこそ、以下のような概念が意味をもつ： ・業務側が見落としていた業務要件 ・開発側が気づいて補足した業務要件 ・業務側から出てきたソフトウェア要件
2019-09-25 19:00:00
きょん＠アジャイルコーチ、システムアーキテクト
@kyon_mm
@j5ik2o @irof @haljik @masuda220 @megascus もっというと、例えばクリーンアーキテクチャとかは技術依存部分はDI的に扱って外側なので、中心部分になれないですよね。だけれども、DDDのみを採用すると決めたならば、ドメインに物理的な技術知識をいれていくってこと？どの書籍かスライドが忘れたけど、そういうのやめろって聞いた記憶が。
2019-09-25 19:51:50
加藤潤一(かとじゅん)
@j5ik2o
@kyon_mm @irof @haljik @masuda220 @megascus なるなる。十把一絡げに技術要素はドメインに入れてはダメといい方は説明が足りないのかなとおもってます。ほかの方の意見も聞いてみたいですが、技術かどうかより、解決したい課題が何かで決めるべきなのかなと思ってます。(過去の僕の資料にもそういう言説あったかも、心より恥じる…
2019-09-25 19:58:14