保守とDDDと私

1

2015.09.19 DevLove関西 「DDD実践者の話をきいてみよう」発表資料

2

保守とDDDと私 安易な改良しないため

ドメイン層注力したいから 保守費確保してね

価値あるアプリのため キレイでいさせて

自己紹介

3

●かわべ たくや

●Twitter : @kawakawa

●大阪にてDDD奮闘中！

プロジェクトは何で評価される？

新規開発プロジェクトの評価は、いつ判るのでしょう

か。運用開始後でしょうか。

ドメインエキスパートも万能ではありません、運用し

てから判る気づきがあるかも知れません。

業務形態が時代に合わせ、変化していくかも知れま

せん。

4

DDDの本領は保守で発揮される

変化する事が運命づけられているアプリ・サービスに

おいて、如何に対応していくのか。

プロジェクトの評価はそこで決まると思っております。

まさにDDDの真骨頂だと思います。

5

価値色々・・

勿論、プロジェクト評価基準は様々あります。

費用だったり、期間だったり、顧客満足度だったり。

一概に良いプロジェクトとは何とは言えないもので

す。

今回は、変化への対応という観点で考えたいと思い

ます。

6

おことわり

保守といっても様々な形態があります。

今からお話しさせて頂く内容は、実際に経験した範

囲での話になります。

7

保守困った事：文化継承

開発チームがそのまま保守チームに移行できたら良

いのですが、エース級プログラマは他開発プロジェク

トに引き抜かれたり、仕様を把握していない新メン

バーが補充されたりします。

人員変更で発生する問題が、文化の継承です。

開発期の文化が途絶えることで、様々な影響が随所

に出てきます。

8

保守困った事：ビジネスロジックダダ漏れ

ドメイン層に注力しないと、簡単にビジネスロジックは

漏れ出します。ダダ漏れです。

保守では、UI変更の依頼も多いのですが、見えな

い危険が多く潜んでいます。

チェックボックスから、ラジオボタンに変えるだけ

でビジネスロジックの意味合いが変わる場合があり

ます。UI変更が与える影響は、なかなか気付けませ

ん（ソースに意図が残らないから）。

9

保守困った事：モデル認識不足

簡単な改修だと思っていたが、意外と深いところまで

モデルを考えないと行けない事もあります。

消費税を例に挙げると、

注文品を発送した時と、返品された時では、時期に

よって郵送料が変わる事があります。

通勤定期の月割（税別）計算も、購入時の税率で計

算しなくてはなりません。

モデルは意外と簡単に、壊れる時は壊れます。10

保守困った事：●●フラグ

改修範囲の影響がどこまで及ぶのか、把握するのは

難しいです。

場合により、新たな●●フラグを用意して、フラグを

立てた時だけ、改修内容が動作するようにしたりしま

す。

改修を重ねるとフラグだらけになり、ドメイン層は見る

も無残な姿に。刻の涙を見ることになります。

11

保守困った事：ジェンガ プログラミング

12

保守困った事：ジェンガ プログラミング

もともと、技術的負債がタップリあるプロジェクトの保

守。DDD以前の問題・・・。

保守期間では大きく負債返済することは難しいので、

２期開発まで待つか、腐敗防止層を導入して、少しづ

ず返済していくか戦略が求められます。

そして、大抵諦めます。

13

保守困った事：ドメインエキスパート不在

開発チームが人員変更すると同じように、顧客の人

員も変わる事があります。

開発時にはエキスパートだった担当者も代替わりし、

当初の意図・目的から、遺脱した要望を出されること

もあります。

費用も時間も確保が難しい保守において、ドメイン層

に大胆なメスを入れることもできず、泣く泣くUI層でお

茶を濁す羽目になります。

14

まとめ（１）

DDDで開発した案件の保守。

DDDではない案件の保守。

様々ありますが、そもそも保守とは何ぞやに突き当

たります。

瑕疵担保期間＋次期大型開発までの繋ぎ役として

保守を見てしまうと、時間・費用の問題に突き当たり

、ドメイン層を守るだけで精一杯です。

15

まとめ（２）

DDDから見れば、永遠の開発期間であってほしいの

ですが、現実問題そうも言ってられません（涙

保守期間で技術的負債を増やしてしまうという、本末

転倒にならないためにも、開発時に如何にドメイン層

に注力できるかが、今考えられる唯一の解決策です

。

保守担当者を少しでも救う為にも、みなさん頑張って

いきましょう！！

16

ご清聴ありがとうございました

17