狠狠撸
Submit Search
设计书からの卒业
?
Download as PPTX, PDF
?
9 likes
?
3,615 views
Fumiyasu Sumiya
Follow
社内用
Read less
Read more
1 of 24
Download now
More Related Content
设计书からの卒业
1.
设计书からの卒业 ~DDDへの誘い~
2.
設計書書きたくない 書く意味無いじゃん
3.
なぜ?
4.
ただの日本語プログラミングに なっているから なぜ?
5.
ソースコードとの二重メンテになるから (設計書はソースコードと乖離する) なぜ?
6.
ソースコードを追った方が 圧倒的に早いから なぜ?
7.
設計書に縛られて プログラミングが不自由になるから なぜ?
8.
?ロジックをゴリゴリ書いてしまっている ?設計書に何を書くべきかわかっていない 日本語プログラミングになっているから 原因
9.
?製造工程で前工程の考慮漏れが発覚 ?クライアントからの仕様変更依頼 ?障害発生時にソースコードのみ修正 ソースコードとの二重メンテになるから 原因
10.
ソースコードを追った方が 圧倒的に早いから ?プログラムはソースコードに記載の通り動いており、 設計書に記載の通り動いているわけではない 原因
11.
設計書に縛られて プログラミングが不自由になるから ?設計書に書いて無いことは出来ない、やらない ?やろうとすると設計書の修正が必要になるので面倒 ?設計書が間違っていたとしてもそれを正とするように なる(クライアントの要望に応じなくなる) ?「それ設計書に書いてあるの?」 原因
12.
设计书に详细なロジックを书いてはならない
13.
コンテキストマップ ?http://d.hatena.ne.jp/asakichy/20110623/1308780754 ?http://tsuyok.hatenablog.com/entry/2013/07/24/220841 ユーザーストーリー ?http://www.slideshare.net/Ryuzee/ss-8332120 ?http://www.slideshare.net/papanda/ss-41638116 ?http://hosukepoi.hatenablog.com/entry/2013/05/30/222338 ユビキタス言語 ?チームで共有する言語 ?プロジェクトにとって最善の用語 ?http://d.hatena.ne.jp/asakichy/20110513/1305239515 クラス図 何を成果物とすべきか
14.
クライアントが??? ?システムを保守しているのは誰か (クライアントはロジックを知ってどうするのか) ?クライアント(システム部含む)にとって設計書は意味のあるものか? ?クライアントは納品された設計書で何をするのか? ?ソースコードの読めないエンジニアは必要ない ?ソースコードの読めないエンジニアにはロジックは必要ない ?設計書修正の工数を減らせるので見積額減らせまーす(適当)
15.
?重要なのはドメインであり、ユビキタス言語である ?設計書にはユーザーストーリーを書くだけに留める ?クラス図を書く ?ユーザーストーリーをクラス図に反映する ?システムを保守する人間がシステムの内部構造を理解していればそれでいい ?設計書に縛られてプログラムが歪になってはいけない ?シナリオ -> モデル
-> コード -> http://j5ik2o.me/blog/2013/05/11/sinario-model-code/ 簡単に
16.
どうすればいい?
17.
ドメイン駆动设计(顿顿顿)しよう
18.
?組織として、ドメインに関する有用なモデルを獲得できる ?事業について、より洗練された正確な定義ができて、さらに深く理解できる ?ドメインエキスパートが、ソフトウェアの設計に貢献できる ?よりよいユーザー体験を提供できる ?モデルとモデルの間に、明確な境界を定められる ?エンタープライズアーキテクチャが、より整理されたものとなる ?アジャイルでイテレーティブなモデリングを、継続的に行える ?戦略的な面でも戦術的な面でも、新しいツールを使える (実践ドメイン駆動設計 (Object Oriented
Selection) p.24 より引用) DDDを採用する事業価値
19.
?クライアントを巻き込む ?ドメインエキスパートを巻き込む(情報システム部ではなく、業務部) ?クライアントが協力してくれないのならば案件を受けてはならない ?クライアントにシステムへの思いがなければ間違いなく炎上する ?我々はクライアントのビジネスにシステムで貢献するのであって御用聞きでもなけ れば、クライアントの操り人形でもないし、ましてや奴隷でもない ?単なる技術屋になってはいけない ?「クライアントがこう言ってるから」ではなく、なぜそうするのか議論せよ ?ユビキタス言語を作る ?ユビキタス言語があれば本当のクライアントと話ができる ?業務にもシステムにも詳しくないクライアントの情報システム部は不要 ?本当にそのシステムを必要としている人と会話が可能となる ?ドメインについて理解する ?ドメインをしっかり設計できていれば最適な技術を選べる (フレームワークも言語も自由。最適なものを選べば良い。) DDDのために
20.
DDD(ドメイン駆動設計)は Scalaがやりやすいらしいっすわー ちなみに
21.
?DDDは銀の弾丸ではない ?DDDを適用すべきでないところもある ?一度DDDが出来てしまえば生産性は今よりも向上するが、そこに辿り着くまでのコストは 掛かる(※どのくらいの数字かはやってみないとわからない) 注意
22.
?組織的に挑戦していかなければならない(ビジネスモデルの改革) ?要件定義で失敗すればそのプロジェクトでの生産性向上は不可能 (もし生産性が高いように見えるのであればリスクを非常に多く積んでいるだけの可能性 があり、本当に生産性が高いのかは疑わしい) ?DDDワンチャン 小手先の生産性向上は限界を迎えている
23.
?http://www.amazon.co.jp/%E3%82%A8%E3%83%AA%E3%83%83%E3%82%AF%E3%83%BB%E3% 82%A8%E3%83%B4%E3%82%A1%E3%83%B3%E3%82%B9%E3%81%AE%E3%83%89%E3%83%A1%E 3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88-IT- Architects%E2%80%99Archive- %E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99% BA%E3%81%AE%E5%AE%9F%E8%B7%B5- %E3%82%A8%E3%83%AA%E3%83%83%E3%82%AF%E3%83%BB%E3%82%A8%E3%83%B4%E3%82% A1%E3%83%B3%E3%82%B9/dp/4798121967 エリック?エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
24.
?http://www.amazon.co.jp/dp/479813161X/ref=pd_lpo_sbs_dp_ss_1?pf_rd_p=187205609&p f_rd_s=lpo-top- stripe&pf_rd_t=201&pf_rd_i=4798121967&pf_rd_m=AN1VRQENFRJN5&pf_rd_r=1T5HEH69P YZB979FV278 実践ドメイン駆動設計 (Object Oriented Selection)
Download