Start
Entdecken
Suche senden
Hochladen
Einloggen
Registrieren
Anzeige
実践的な設計って、なんだろう?
Melden
増田 亨
Folgen
ソフトウェアシステムの設計・構築 um システム設計
17. May 2014
•
0 gefällt mir
161 gefällt mir
×
Sei der Erste, dem dies gefällt
Mehr anzeigen
•
35,934 Aufrufe
Aufrufe
×
Aufrufe insgesamt
0
Auf Slideshare
0
Aus Einbettungen
0
Anzahl der Einbettungen
0
Check these out next
正しいものを正しく作る塾-設計コース
増田 亨
リーンなコードを書こう:実践的なオブジェクト指向設計
増田 亨
3週連続DDDその3 ドメイン駆動設計 戦略的設計
増田 亨
ドメイン駆動設計 基本を理解する
増田 亨
ちいさなオブジェクトでドメインモデルを組み立てる
増田 亨
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
DDD sample code explained in Java
増田 亨
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
1
von
135
Top clipped slide
実践的な設計って、なんだろう?
17. May 2014
•
0 gefällt mir
161 gefällt mir
×
Sei der Erste, dem dies gefällt
Mehr anzeigen
•
35,934 Aufrufe
Aufrufe
×
Aufrufe insgesamt
0
Auf Slideshare
0
Aus Einbettungen
0
Anzahl der Einbettungen
0
Jetzt herunterladen
Downloaden Sie, um offline zu lesen
Melden
Technologie
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計
増田 亨
Folgen
ソフトウェアシステムの設計・構築 um システム設計
Anzeige
Anzeige
Anzeige
Recomendados
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
29.7K Aufrufe
•
95 Folien
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
94.3K Aufrufe
•
76 Folien
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
47.6K Aufrufe
•
65 Folien
ドメイン駆動設計 の 実践 Part3 DDD
増田 亨
8.6K Aufrufe
•
23 Folien
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
36.4K Aufrufe
•
47 Folien
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
32.2K Aufrufe
•
113 Folien
Más contenido relacionado
Presentaciones para ti
(20)
正しいものを正しく作る塾-設計コース
増田 亨
•
9.4K Aufrufe
リーンなコードを書こう:実践的なオブジェクト指向設計
増田 亨
•
15.5K Aufrufe
3週連続DDDその3 ドメイン駆動設計 戦略的設計
増田 亨
•
14.6K Aufrufe
ドメイン駆動設計 基本を理解する
増田 亨
•
117K Aufrufe
ちいさなオブジェクトでドメインモデルを組み立てる
増田 亨
•
14.9K Aufrufe
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
•
47.6K Aufrufe
DDD sample code explained in Java
増田 亨
•
21.4K Aufrufe
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
•
137.5K Aufrufe
ドメインロジックの実装方法とドメイン駆動設計
Tadayoshi Sato
•
14.7K Aufrufe
ドメインオブジェクトの設計ガイドライン
増田 亨
•
3.5K Aufrufe
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
•
15.5K Aufrufe
例外設計における大罪
Takuto Wada
•
66.4K Aufrufe
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
Koichiro Matsuoka
•
20.1K Aufrufe
ドメイン駆動設計をゲーム開発に活かす
増田 亨
•
4.6K Aufrufe
ドメイン駆動設計 コアドメインを語り合ってみよう
増田 亨
•
2.5K Aufrufe
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
•
64.1K Aufrufe
Unityでオニオンアーキテクチャ
torisoup
•
9.2K Aufrufe
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
•
16.5K Aufrufe
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
増田 亨
•
14.4K Aufrufe
いまなぜドメイン駆動設計か
増田 亨
•
15.5K Aufrufe
Destacado
(7)
技術者の働き方/ リモートワークという働き方 powered byドメイン駆動設計
GuildWorks
•
7.3K Aufrufe
現場コーチから見えてきた越境する現場の3つの特徴
GuildWorks
•
6.3K Aufrufe
現場で役立つシステム設計の原則
増田 亨
•
8.5K Aufrufe
データベース設計徹底指南
Mikiya Okuno
•
113.9K Aufrufe
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
•
159.5K Aufrufe
越境する情シス:進化可能なアーキテクチャを手に入れる
増田 亨
•
5.8K Aufrufe
当たり前を当たり前に:Agile2017レポート
LINE Corporation
•
6K Aufrufe
Anzeige
Similar a 実践的な設計って、なんだろう?
(20)
Hey It's Not My TDD!
Yasui Tsutomu
•
2.4K Aufrufe
Workshop Facilitation
Naoka MISAWA
•
13.6K Aufrufe
Hokkaido.pm #11
moznion
•
6K Aufrufe
13_B_5 Who is a architect?
Atsushi Fukui
•
1.2K Aufrufe
Clarity 2019 で デザインシステムの課題は人なんだと痛感した話
Yusuke Goto
•
3.4K Aufrufe
アジャイル実践における開発環境の変化〜要求の捉え方、プロジェクト運営、ツール支援
智治 長沢
•
2.8K Aufrufe
Information20120312
b-slash
•
629 Aufrufe
開発プロセスの話
Makiko Nakasato
•
490 Aufrufe
アジャイル開発はWhyから始まる
toshihiro ichitani
•
15.7K Aufrufe
とちぎテストの会議パネルディスカッションポジペ
H Iseri
•
597 Aufrufe
15 c5 dad
Noriyuki Egi
•
3.5K Aufrufe
2014-10-27 #ssmjp 腹を割って話そう (運用xセキュリティ)
Operation Lab, LLC.
•
5K Aufrufe
It業界の優良企業の見つけ方 20140502 黒田
Yusuke Kuroda
•
1.4K Aufrufe
デザイン仕様書(ガイド)の書き方 (初歩者用)
witstudio
•
56.7K Aufrufe
Sustainable Software Development
Kenji Hiranabe
•
490 Aufrufe
[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用
masashi takehara
•
1.2K Aufrufe
企画-計画-開発-ビルド-デプロイ 価値のパイプラインできてますか?【字幕つき】 #kansumiA2 #devsumi
智治 長沢
•
3.6K Aufrufe
今、おさえておきたい DevOps
智治 長沢
•
9.6K Aufrufe
0から始めるUXデザイン(UXデザインの組織を作る)
Jiji Kim
•
10.8K Aufrufe
Design Thinking - מארגון ממוקד טכנולוגיה לארגון ממוקד משתמש
Hen Shkedi
•
1.5K Aufrufe
Más de 増田 亨
(20)
ソフトウェア開発のやり方の改善
増田 亨
•
6.5K Aufrufe
事業活動モデル・システム機能モデル・ビジネスロジックの記述
増田 亨
•
1.5K Aufrufe
オブジェクト指向プログラミングの現在・過去・未来
増田 亨
•
6.5K Aufrufe
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
増田 亨
•
13.8K Aufrufe
ドメイン駆動設計という設計スタイル
増田 亨
•
17.3K Aufrufe
プロダクトづくりのためのソフトウェア設計スタイル
増田 亨
•
4.6K Aufrufe
ソフトウェア設計の学び方を考える
増田 亨
•
25K Aufrufe
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
増田 亨
•
3.7K Aufrufe
ドメイン駆動設計の正しい歩き方
増田 亨
•
25.1K Aufrufe
マイクロサービス 4つの分割アプローチ
増田 亨
•
40.3K Aufrufe
ビジネスルールの複雑さに立ち向かう
増田 亨
•
12.1K Aufrufe
ソフトウェアの核心にある複雑さに立ち向かう
増田 亨
•
10.5K Aufrufe
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
•
19.6K Aufrufe
ドメイン駆動設計 本格入門
増田 亨
•
43.9K Aufrufe
アジャイルなソフトウェア設計を目指して
増田 亨
•
12.1K Aufrufe
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
•
14.2K Aufrufe
SoR 2.0 summary
増田 亨
•
1.3K Aufrufe
毎日が越境だ!
増田 亨
•
10.5K Aufrufe
SoR 2.0 基幹システムの再定義と再構築
増田 亨
•
9.1K Aufrufe
ドメイン駆動設計とは何か 【入門編】
増田 亨
•
13.1K Aufrufe
Anzeige
Último
(20)
初学者のためのプロンプトエンジニアリング実践.pptx
Akifumi Niida
•
376 Aufrufe
通信プロトコルについて
iPride Co., Ltd.
•
0 Aufrufe
CDLEハッカソン2022参加報告.pdf
SHOIWA1
•
7 Aufrufe
Üslup ve tercüme.pdf
1Hmmtks
•
2 Aufrufe
SoftwareControl.pdf
ssusercd9928
•
6 Aufrufe
MC-800DMT intrusion detector manual
Vedard Security Alarm System Store
•
2 Aufrufe
統計学の攻略_推測統計学の考え方.pdf
akipii Oga
•
138 Aufrufe
JSTQB_テストマネジメントとレビュープロセス.pdf
akipii Oga
•
113 Aufrufe
☀️【杜兰大学毕业证成绩单留学生首选】
2125nuh
•
2 Aufrufe
留信网认证可查【皇家霍洛威学院文凭证书毕业证购买】
32lkhng
•
2 Aufrufe
Forguncy8 製品概要 202305.pptx
フォーガンシー
•
38 Aufrufe
量子論.pdf
hiro150493
•
5 Aufrufe
【DL輪読会】Egocentric Video Task Translation (CVPR 2023 Highlight)
Deep Learning JP
•
6 Aufrufe
UAV写真・レーザー測量test.pptx
ssuserb48d2b1
•
14 Aufrufe
☀️【卡尔顿大学毕业证成绩单留学生首选】
15sad
•
2 Aufrufe
ヘッドレス化したbaserCMS5とその機能
Ryuji Egashira
•
10 Aufrufe
モバイル・クラウド・コンピューティング-データを如何に格納し、組み合わせ、情報として引き出すか
Masahiko Funaki
•
2 Aufrufe
Oracle Cloud Infrastructure:2023年5月度サービス・アップデート
オラクルエンジニア通信
•
29 Aufrufe
ネットワークパケットブローカー市場.pdf
HinaMiyazu
•
6 Aufrufe
20230523_IoTLT_vol99_kitazaki_v1.pdf
Ayachika Kitazaki
•
107 Aufrufe
実践的な設計って、なんだろう?
実践的な設計って なんだろう? ギルドワークス株式会社 増田 亨 DevLove Nagoya
2014/5/19
Agile is dead. TDD
is dead. Long live the DDD.
正しいものを正しくつくる!!
プロセスやツールよりも 正しいものを正しくつくる!!
たいせつなのは設計なんですよ プロセスやツールよりも 正しいものを正しくつくる!!
たいせつなのは設計なんですよ 設計 プロセスやツールよりも 正しいものを正しくつくる!!
設計ってなんだろう?
コードを整理整頓する工夫 設計ってなんだろう?
なんのために?
なんのために? 変更コストを下げたい
設計とは 変更コストを下げるために コードを整理整頓する 実践的な工夫
「実践的」ってなんだろう?
「実践的」ってなんだろう? 全体 部分
「実践的」ってなんだろう? 全体 部分 長期 短期
「実践的」ってなんだろう? 全体 部分 広さ 深さ 長期
短期
「実践的」ってなんだろう? 全体 部分 論理 感覚 広さ
深さ 長期 短期
「実践的」ってなんだろう? 全体 部分 論理 感覚 理想
現実 広さ 深さ 長期 短期
「実践的」ってなんだろう? 全体 部分 論理 感覚 理想
現実 広さ 深さ 長期 短期 行ったり来たり動きながらバランスを取る
実践的な設計 全体 部分 論理 感覚 理想
現実 広さ 深さ 長期 短期 左右のバランスを取りながら 変更コストを下げる工夫を続ける
具体的にどうやるの?
具体的にどうやるの? 変更コストの原因を知る
変更コストの最大の敵
変更コストの最大の敵 重複したコード
変更コストの最大の敵 重複したコード あちこち調べ
変更コストの最大の敵 重複したコード あちこち調べ あちこち直し
変更コストの最大の敵 重複したコード あちこち調べ あちこち直し 思わぬ副作用と格闘する
重複したコードのいやな臭い
重複したコードのいやな臭い 長いメソッド
重複したコードのいやな臭い 長いメソッド 大きなクラス
重複したコードのいやな臭い 長いメソッド 大きなクラス たくさんの引数
重複したコードのいやな臭い 長いメソッド 大きなクラス たくさんの引数 同じコードがあちこちに 書かれている臭いがする
マスダ流 重複の臭い判定基準
マスダ流 重複の臭い判定基準 クラス 50行 メソッド
3行 引数 0
マスダ流 重複の臭い判定基準 クラス 50行 メソッド
3行 引数 0 これを超えたら警戒警報
マスダ流 重複の臭い判定基準 クラス 50行
100行 メソッド 3行 5行 引数 0 1
マスダ流 重複の臭い判定基準 クラス 50行
100行 メソッド 3行 5行 引数 0 1 これを超えたら 一息いれて設計やり直し
コード整理の基本パターン
コード整理の基本パターン Value Object
コード整理の基本パターン Value Object 振る舞いを持った区分
コード整理の基本パターン Value Object 振る舞いを持った区分 ファーストクラスコレクション
Value Object パターン
Value Object パターン privateなデータ
+ public な振る舞い
Value Object パターン privateなデータ
+ public な振る舞い 不変(immutable)
Value Object パターン privateなデータ
+ public な振る舞い 不変(immutable) 例:String型
Value Object パターン privateなデータ
+ public な振る舞い 不変(immutable) private final char value[]; private final int count; String substring() { … } String trim() { … } int length() { … } boolean startsWith { … } 例:String型
Value Object パターン getValue()しない
Value Object パターン データをget()して 加工/計算/判断すると、 ロジックが散らばる
Value Object パターン データをget()して 加工/計算/判断すると、 ロジックが散らばる だから
Value Object パターン データをget()して 加工/計算/判断すると、 ロジックが散らばる だから データのある場所に ロジックを寄せる
Value Object パターン setValue()しない
Value Object パターン データを 加工/計算/判断して set()すると 状態管理のコードが散らばる
Value Object パターン データを 加工/計算/判断して set()すると 状態管理のコードが散らばる だから
Value Object パターン データを 加工/計算/判断して set()すると 状態管理のコードが散らばる だから 不変オブジェクトにする
業務アプリの Value Object
業務アプリの Value Object String StringBuilder List<String>
業務アプリの Value Object String StringBuilder List<String>+業務ロジック
業務アプリの Value Object String StringBuilder List<String> 商品名称(ProductName) 備考(Remarks) 摘要(Abstract)
+業務ロジック
業務アプリの Value Object String StringBuilder List<String> BigDecimal Integer 商品名称(ProductName) 備考(Remarks) 摘要(Abstract)
+業務ロジック
業務アプリの Value Object String StringBuilder List<String> BigDecimal Integer 商品名称(ProductName) 備考(Remarks) 摘要(Abstract)
+業務ロジック +業務ロジック
業務アプリの Value Object String StringBuilder List<String> BigDecimal Integer 金額(Money) 数量(Quantity) 単位(Unit) 商品名称(ProductName) 備考(Remarks) 摘要(Abstract)
+業務ロジック +業務ロジック
業務アプリの Value Object String StringBuilder List<String> BigDecimal Integer Calendar Date/Long 金額(Money) 数量(Quantity) 単位(Unit) 商品名称(ProductName) 備考(Remarks) 摘要(Abstract)
+業務ロジック +業務ロジック
業務アプリの Value Object String StringBuilder List<String> BigDecimal Integer Caleldar Date/Long 金額(Money) 数量(Quantity) 単位(Unit) 商品名称(ProductName) 備考(Remarks) 摘要(Abstract)
+業務ロジック +業務ロジック +業務ロジック
業務アプリの Value Object String StringBuilder List<String> BigDecimal Integer Caleldar Date/Long 起算日(InitialDate) 期限(DueDate) 有効期間(ValidTerm) 金額(Money) 数量(Quantity) 単位(Unit) 商品名称(ProductName) 備考(Remarks) 摘要(Abstract)
+業務ロジック +業務ロジック +業務ロジック
業務アプリの Value Object String StringBuilder List<String> BigDecimal Integer Caleldar Date/Long 起算日(InitialDate) 期限(DueDate) 有効期間(ValidTerm) 金額(Money) 数量(Quantity) 単位(Unit) 商品名称(ProductName) 備考(Remarks) 摘要(Abstract)
+業務ロジック +業務ロジック +業務ロジック
振る舞いを持った区分
振る舞いを持った区分 enum MemberType { normal, silver,
gold }
振る舞いを持った区分 MemberType type =
gold; gold.chargeRate() gold.description() gold.isLimitOver()
振る舞いを持った区分 区分定数に 業務の知識を持たせる MemberType type =
gold; gold.chargeRate() gold.description() gold.isLimitOver()
振る舞いを持った区分 CodeIQ で出題中 (6月2日まで) 「顧客区分」を列挙型で宣言し、 「顧客区分」ごとに異なる振る舞い を持たせてみましょう。
ファーストクラスコレクション
ファーストクラスコレクション privateなコレククション + public な振る舞い private
final char value[]; private final int count; String substring() { … } String trim() { … } int length() { … } boolean startsWith { … } 例:String型
ファーストクラスコレクション コレクションをget()して 操作すると あちこちに同じコードが登場する
ファーストクラスコレクション コレクションをget()して 操作すると あちこちに同じコードが登場する だから
ファーストクラスコレクション コレクションをget()して 操作すると あちこちに同じコードが登場する だから コレクションを持つクラスに ループ処理を閉じ込めて
ファーストクラスコレクション コレクションをget()して 操作すると あちこちに同じコードが登場する だから コレクションを持つクラスに ループ処理を閉じ込めて 一元管理する
ファーストクラスコレクション
ファーストクラスコレクション 顧客一覧 (Customers)
ファーストクラスコレクション 顧客一覧 注文明細 (Customers) (OrderLines)
ファーストクラスコレクション 顧客一覧 注文明細 利用履歴 (Customers) (OrderLines) (UsageHistory)
ファーストクラスコレクション 顧客一覧 注文明細 利用履歴 To-do リスト (Customers) (OrderLines) (UsageHistory) (ToDoList)
ファーストクラスコレクション 顧客一覧 注文明細 利用履歴 To-do リスト 未読一覧 (Customers) (OrderLines) (UsageHistory) (ToDoList) (UnReads)
ファーストクラスコレクション 顧客一覧 注文明細 利用履歴 To-do リスト 未読一覧 選択候補 (Customers) (OrderLines) (UsageHistory) (ToDoList) (UnReads) (Candidates)
コードの整理 アンチパターン
コードの整理 アンチパターン Smart UI
コードの整理 アンチパターン Smart UI トランザクションスクリプト
コードの整理 アンチパターン Smart UI トランザクションスクリプト Active
Record
コードの整理 アンチパターン Smart UI トランザクションスクリプト Active
Record 必ずコードが重複する
コードの整理 アンチパターン 画面仕様書
コードの整理 アンチパターン 画面仕様書 画面単位で開発
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複 機能仕様書
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複 機能仕様書 機能単位で開発
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複 機能仕様書 機能単位で開発 トランザクション スクリプト
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複 機能Aと機能Bで コード重複機能仕様書 機能単位で開発 トランザクション スクリプト
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複 機能Aと機能Bで コード重複機能仕様書 機能単位で開発 テーブル 定義書 トランザクション スクリプト
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複 機能Aと機能Bで コード重複機能仕様書 機能単位で開発 テーブル単位で開発 テーブル 定義書 トランザクション スクリプト
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複 機能Aと機能Bで コード重複機能仕様書 機能単位で開発 テーブル単位で開発 テーブル 定義書 トランザクション スクリプト Active Record
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複 機能Aと機能Bで コード重複 テーブルに関連 づかないコードの 氾濫と重複 機能仕様書 機能単位で開発 テーブル単位で開発 テーブル 定義書 トランザクション スクリプト Active Record
コードの整理 アンチパターン 画面仕様書 画面単位で開発 Smart UI プログラム 画面Aと画面Bで コード重複 機能Aと機能Bで コード重複 テーブルに関連 づかないコードの 氾濫と重複 機能仕様書 機能単位で開発 テーブル単位で開発 テーブル 定義書 トランザクション スクリプト Active Record
コードの整理 グッドパターン
コードの整理 グッドパターン 三層+ドメインモデル
コードの整理 グッドパターン プレゼンテーション層 ビュー 画面コントローラ 三層+ドメインモデル ドメインモデル
コードの整理 グッドパターン プレゼンテーション層 ビュー 画面コントローラ 三層+ドメインモデル ドメインモデル 業務ロジック
コードの整理 グッドパターン ビジネスロジック層 (サービス層) アプリケーション コントローラ 三層+ドメインモデル 業務ロジック ドメインモデル プレゼンテーション層 ビュー 画面コントローラ
コードの整理 グッドパターン 三層+ドメインモデル ドメインモデル 業務ロジック 業務ロジック プレゼンテーション層 ビュー 画面コントローラ ビジネスロジック層 (サービス層) アプリケーション コントローラ
コードの整理 グッドパターン データアクセス層 データアクセス オブジェクト 三層+ドメインモデル 業務ロジック 業務ロジック ドメインモデル ビジネスロジック層 (サービス層) アプリケーション コントローラ プレゼンテーション層 ビュー 画面コントローラ
コードの整理 グッドパターン データアクセス層 データアクセス オブジェクト 三層+ドメインモデル ドメインモデル 業務ロジック 業務ロジック 業務ロジック プレゼンテーション層 ビュー 画面コントローラ ビジネスロジック層 (サービス層) アプリケーション コントローラ
コードの整理 グッドパターン データアクセス層 データアクセス オブジェクト 三層+ドメインモデル ドメインモデル 業務ロジック 業務ロジック 業務ロジック プレゼンテーション層 ビュー 画面コントローラ ビジネスロジック層 (サービス層) アプリケーション コントローラ 三層に散らばりがちな 業務ロジックの断片を ここに集めて一元化する
ドメインモデルの設計のコツ
ドメインモデルの設計のコツ 画面単位に設計しない
ドメインモデルの設計のコツ 画面単位に設計しない 機能単位に設計しない
ドメインモデルの設計のコツ 画面単位で設計しない 機能単位に設計しない テーブル単位に設計しない
じゃあどうすればよい?
じゃあどうすればよい? 業務の関心事を表現できるように クラスを考える
業務の関心事(業務知識)
業務の関心事(業務知識) 1. ポイントカード口座会員 2. 購入金額に応じてポイントを提供 3.
本人確認をすることがある 4. 精算後のポイント加算はできない 5. ポイントの有効期限は2年 6. ポイントは換金しない 7. 返品・交換により累計ポイントが マイナスになる場合は現金で精算
ドメインモデル(関心事の模型) 会員 (entity) ポイント口座 (account) 購入 (event) 返品・交換 (event) 有効期限 (policy) 購買履歴 (status) 換金率 (policy) 残高 (status) 本人確認情報 (description) 加算する 参照する
ドメインモデル(関心事の模型) 会員 (entity) ポイント口座 (account) 購入 (event) 返品・交換 (event) 有効期限 (policy) 購買履歴 (status) 換金率 (policy) 残高 (status) 本人確認情報 (description) 加算する 参照する 画面/機能/テーブル単位のコード整理とは 異なる切り口のクラス設計
なぜドメインモデルなの?
なぜドメインモデルなの? コードが重複しない
なぜドメインモデルなの? コードが重複しない 変更が簡単
なぜコードが重複しないか?
なぜコードが重複しないか? 関心事単位の整理だから
なぜコードが重複しないか? 関心事単位の整理だから 画面/機能/テーブル単位の コード整理は重複する
なぜ変更が簡単か?
なぜ変更が簡単か? 仕様変更は業務から発生する
なぜ変更が簡単か? 仕様変更は業務から発生する 業務の関心事単位のクラスなら 変更箇所を1対1で特定できる
なぜ変更が簡単か? 仕様変更は業務から発生する 業務の関心事単位のクラスなら 変更箇所を1対1で特定できる 業務の関心事の依存関係が クラスの依存関係になっている
なぜ変更が簡単か? 仕様変更は業務から発生する 業務の関心事単位のクラスなら 変更箇所を1対1で特定できる 業務の関心事の依存関係が クラスの依存関係になっている 影響範囲がわかりやすい
なぜ変更が簡単か? 仕様変更は業務から発生する 業務の関心事単位のクラスなら 変更箇所を1対1で特定できる 業務の関心事の依存関係が クラスの依存関係になっている 影響範囲がわかりやすい 変更の対象箇所以外でわけの わからない副作用がおきない
ドメインモデル(関心事の模型) 会員 (entity) ポイント口座 (account) 購入 (event) 返品・交換 (event) 有効期限 (policy) 購買履歴 (status) 換金率 (policy) 残高 (status) 本人確認情報 (description) 加算する 参照する 画面/機能/テーブル単位のコード整理とは 異なる切り口のクラス設計
コードの整理 グッドパターン データアクセス層 データアクセス オブジェクト 三層+ドメインモデル ドメインモデル 業務ロジック 業務ロジック 業務ロジック プレゼンテーション層 ビュー 画面コントローラ ビジネスロジック層 (サービス層) アプリケーション コントローラ 三層に散らばりがちな 業務ロジックの断片を ここに集めて一元化する
たいせつなのは設計なんですよ 設計 プロセスやツールよりも 正しいものを正しくつくる!!
設計とは 変更コストを下げるために コードを整理整頓する 実践的な工夫
Anzeige