週末DDDトーク（3月第一週）

かわべ　たくや @kawakawa

"プチ"ドメイン駆動設計導入してみて佳境迎えているけど、プログラマー側視点から見ると、分業化がしやすい。ドメイン毎に小さいAPIを作っている感じ。 ・・・ただし今、結合試験でパフォーマンス問題に悩まされている。 コアドメインに注力できなかったのが原因かな。

増田 亨 @masuda220

@kawakawa パフォーマンス問題は、ドメイン駆動設計では悪くない兆候だと思います。改善のリファクタリングに取り組むわけですが、その時も、テクニカルな改善よりも、モデルが間違っていないかの検討が大切かと。業務的に間違ったことをやろうとしているから遅いのではないか？

けんじ_最新_コピー @fukanoya

@masuda220 @kawakawa 業務的に間違った事とありますが、もし業務自体が陳腐化している部分がある時、業務フローを再検討するのは難しい時もあると思いますが、対処はどうされますでしょうか？　横からで本当にすいませんがご助言頂ければ幸いです。

増田 亨 @masuda220

@fukanoya @kawakawa 業務的に間違っている、というのは業務の手順や構造と、処理の順番や構造がかけ離れていることを意図していました。わかりにくかったですね。すみません。業務フローや業務ルールがあまりにひどい場合は、改善を提案するようにしています。ダメ元で w

HARADA Kiro @haradakiro

@masuda220 @fukanoya @kawakawa そこで、ちょっとずつ機能をリリースして、業務がどう動くかを観察できるのが、DDD/Scrumの一番のメリットだと思ってます。業務を変えられる可能性を、ソフトウェアの力を借りて試す。

けんじ_最新_コピー @fukanoya

@haradakiro @masuda220 @kawakawa 原田さん　DDD/Scrumで業務を変えられる可能性をソフトウェアの力を借りて試す　ワーク受けたのでに、そこまで考えた事もなかったです。ありがとうございます。

HARADA Kiro @haradakiro

@fukanoya @masuda220 @kawakawa あのワークはまだぜんぜん完成に遠いので、また懲りずにお付き合いください。

かわべ　たくや @kawakawa

@haradakiro @fukanoya @masuda220 中々返答できずスミマセン。今回のパフォーマンス問題の中心は、通信がボトルネックで一定数以上負荷がかかると通信速度が極端に遅くなるということです。しかし原因はハードではなく、ソフトにあったという処がミソかなと。

かわべ　たくや @kawakawa

@haradakiro @fukanoya @masuda220 ドメインに詳しい人は、通信が爆発的に増える可能性は事前に認知していたが、それが通信（API）担当者と共有できていなかったのが直接の原因ですが・・・「知ってはいたが認識が及ばなかった」に近いかなと。悩むところです。

増田 亨 @masuda220

@kawakawa @haradakiro @fukanoya ユビキタス言語を使った意図伝達という文脈だと、「爆発的」という言葉が出てきた時に、その曖昧性に敏感に反応して、もっと具体的な言葉への言い換えを意識的にやってみる、とかかなあ。

かわべ　たくや @kawakawa

@masuda220 @haradakiro @fukanoya 有難うございます。そうですね。コアドメインに全員で取り組めば、だれか1人は「爆発的」という言葉の意味に疑問を持つ人は出たかもしれません。もしくはコアドメインだけ早めにリリースすれば気づけたかもしれません。

かわべ　たくや @kawakawa

@masuda220 @haradakiro @fukanoya 今回は、分業しやすいからとドメインごとに進める危険性を知ることができました。それにまして、DDDはウォーターフォールと相性問題も改めて知ることができましたｗｗｗ。

増田 亨 @masuda220

@kawakawa @haradakiro @fukanoya やって見たからこそ、わかること、学べることって、たくさんありますよね。

かわべ　たくや @kawakawa

@masuda220 @haradakiro @fukanoya はい、ほんとそうだと思います。DDDでも説かれていますが、FeedBackLoopの重要性はヒシヒシと感じます。 ウォーターフォールだとモデル実装⇒検証の期間がやはり長くなりますね。

増田 亨 @masuda220

@kawakawa @haradakiro @fukanoya 「問題が発覚した時には手遅れ」を、どうやって防ぐかですよね。ウォーターフォールで上流でがんばればそれが防げるケースって、ビジネスや技術が相当枯れて固定的な状況だけ。でも、いまどきそんな状況はないですよね。

けんじ_最新_コピー @fukanoya

@masuda220 @kawakawa @haradakiro 私の経験上での話ですが、上流行程に何かしらのチエックリストがあれば少し改善されるかも。SIで常駐作業している時、基本設計レビュー議事録見たりしますが、参加者の暗黙知による指摘がほぼ全てに感じます。

増田 亨 @masuda220

@fukanoya @kawakawa @haradakiro レビュー自体には参加していない？　SIモデルだと、開発者がそういう場で会話に参加するっていうことはないんでしょうかねえ。

けんじ_最新_コピー @fukanoya

@masuda220 @kawakawa @haradakiro 言葉が足りませんでした。自社からSIに常駐させられて詳細設計以降をする時です。ないと言えばないかもWFで行程終わった扱いw。担当者に直接聞きますがレビュー議事録に設計の経緯やコンセプトを拾える事が多いです。

増田 亨 @masuda220

@fukanoya @kawakawa @haradakiro ああ、そういう状況なんですね。そうやって経緯やコンセプトを読み取ってもらえれば、議事録も、役に立ちますね。もう２０年くらい、そういう現場からは離れちゃったので、実感がありませんが。