SlideShare a Scribd company logo
1 of 94
Download to read offline
変更を楽で安全に
アジャイルなソフトウエア設計を目指して
有限会社 システム設計
増田 亨
ソフトウェアの開発
ソフトウェアの開発 = プログラミング
プログラミング = 設計
設計 = ソースコードで表現
よい設計とは?
よい設計とは?
変更が楽で安全であること
ソフトウェア開発のさまざまな課題
開発スコープ
開発スピード
性能問題
ビジネス要求
費用
開発の労力
セキュリティ
要件
安定運用
操作性
機能追加
データ管理
外部連携
バグ対応
個人情報保護
ソフトウェアの変更容易性
変更が
楽で安全
開発スコープ
開発スピード
性能問題
ビジネス要求
開発費用
開発の労力
セキュリティ
対策
安定運用
操作性
機能追加
データ管理 外部連携
バグ対応
個人情報保護
変更が
やっかいで危険
開発スコープ
開発スピード
性能問題
ビジネス要求
開発費用
開発の労力
セキュリティ
対策
安定運用
操作性
機能追加
データ管理 外部連携
バグ対応
個人情報保護
なぜ変更がやっかいで危険になるのか?
硬直したモジュール構造
ソースファイルの肥大化とコードの重複
動けばOK症候群
力ずくのプログラミング
硬直化したモジュール構造
開発のスタイル 技法やドキュメント 関心の焦点 モジュール構造
機能分割駆動
三階層の機能一覧/機能詳細
部門/業務/職務の分解
アプリケーション層
トランザクション
スクリプト
データモデル駆動
ER図
テーブル定義書
CRUD分析
データソース層
データベーススクリプト
スマート Entity
ワークフロー・
ユースケース駆動
アクテビティ図
ユースケースモデル
ユースケース記述
アプリケーション層
トランザクション
スクリプト
画面/API 駆動
(インタフェース駆動)
ワイヤフレーム
画面一覧/画面遷移
API一覧/API定義
プレゼンテーション層
スマートUI
ファットコントローラ
開発のスタイルとモジュール構造
どの開発スタイルでも、データ処理の手続き単位のモジュールになる
(モジュール=ソースコードファイルの分割単位)
手続き的なモジュール構造と変化への対応
モジュール構造(ファイル単位)は変えない
既存のソースファイルに変更をねじ込む
ロジックの部分的な再利用はできない/やらない
モジュールの組み立てなおしはできない/やらない
モジュール構造を変えずに変更をねじ込む
その場しのぎの if 文の追加
その場しのぎの switch文のcaseの追加
その場しのぎの enum(区分定数)の追加
丸ごとコピーして一部修正
同じ計算式や類似の条件判定があちこちに重複する
さらに状況を悪化させる悪しき習慣
動けばOK症候群
その場しのぎの修正
いいかげんな名前づけ
ゆがんだ分岐構造の放置
重複コード/類似コードの放置
使わなくなったコードの放置
力ずくのプログラミングの横行
言語が提供する型だけでがんばる
int, long, boolean
String, BigDecimal, LocalDate, LocalTime,
List, Map, Set
大きなクラス、長いメソッド、たくさんのパラメータでがんばる
硬直したモジュール構造
肥大化するソースファイル
動けばOK症候群
力ずくのプログラミングの横行
その繰り返しの結果…
変更が
やっかいで危険
開発スコープ
開発スピード
性能問題
ビジネス要求
開発費用
開発の労力
セキュリティ
対策
安定運用
操作性
機能追加
データ管理 外部連携
バグ対応
個人情報保護
変更を楽で安全にする設計技法
変更が
楽で安全
開発スコープ
開発スピード
性能問題
ビジネス要求
開発費用
開発の労力
セキュリティ
対策
安定運用
操作性
機能追加
データ管理 外部連携
バグ対応
個人情報保護
アジャイルなソフトウェア設計
私たちは、ソフトウェア開発の実践を通じて
よりよい設計方法を見つけつつある
データや機能よりビジネスルールを
手続き的プログラミングより型指向のプログラミングを
動くだけのソフトウェアより読みやすいソフトウェアを
バックログより全体像を
ビジネスルールの分離
型指向のプログラミング
コードの読みやすさに投資する
全体を見渡す習慣
変更を楽で安全にする4つの根底技法
ビジネスルールの分離
型指向のプログラミング
コードの読みやすさに投資する
全体を見渡す習慣
変更を楽で安全にする4つの根底技法
ビジネスルールの記述を
独立したモジュールに分離する
ビジネスルールの記述を独立させる
プレゼンテーション層の
モジュール群
アプリケーション層の
モジュール群
データソース層の
モジュール群
ビジネスルールを
記述したモジュール群
利用する
ソフトウエアが複雑になる理由
ビジネスルール
金額、数量、期日、場所などの計算と判定
ビジネスルールを適用する条件による分岐
顧客区分、商品種別、有効期間、地域区分、金額区分、数量区分、
取引種類、取引状態、支払い方法、支払いタイミング、
割り増し条件、割引条件、キャンセル可能条件、…
従来のモジュール構造とビジネスルール
トランザクションスクリプト
機能(データ処理手続き)で縦割りした蛸壺式モジュール群
ビジネスルールの記述、特に条件判定が、
あちこちのモジュールに分散し、かつ、重複する
変更がやっかいで危険
ビジネスルールの記述を独立させる
プレゼンテーション層の
モジュール群
アプリケーション層の
モジュール群
データソース層の
モジュール群
ビジネスルールを
記述したモジュール群
利用する
ビジネスルールの記述を独立させる効果
プレゼンテーション層のモジュール群がシンプルになる
アプリケーション層のモジュール群がシンプルになる
データソース層のモジュール群がシンプルになる
三つの層から区分判定などの条件分岐が激減する
三つの層のモジュール群の設計がパターン化し安定する
ビジネスルール層は?
ビジネスルールを記述するモジュール群に
複雑さが集中する
ビジネスルールをわかりやすく整理できる
設計スタイルを採用する
ビジネスルールの分離
型指向のプログラミング
コードの読みやすさに投資する
全体を見渡す習慣
変更を楽で安全にする4つの根底技法
型指向のプログラミング
ビジネスルール(計算/判定)の記述をモジュール化する基本
値の種類(=型)ごとにクラス(モジュール)定義する
例:数値を扱う BigDecimal型, 日付を扱う LocalDate型
ただし、個々のビジネスルールを記述するには汎用的すぎる
型指向のプログラミング
ビジネスルールに登場する値を分類する
値の種類(=型)ごとに、独自のクラスを定義する
値の種類ごとに有効な値の範囲を定義する
値の種類ごとに必要な計算・判定のロジックを特定する
ビジネスルールを
型指向のプログラミングで記述する
ビジネスルールを記述する3要素
Fact 事実の表現
ビジネスの状況の記録や通知に使う型
・ 数値、日付、場所、識別番号、名称、…
Rule Factを使った
計算や判定のロジック
計算式
同一性の判定式
大小の比較式
Goal 知りたいこと 計算結果や判定結果を表現する型
ビジネスルールをFact-Rule-Goalで記述する
3つの基本パターン
値オブジェクト
ロジックを持ったenum
コレクションのカプセル化
値オブジェクト
値オブジェクトとは?
 Fact の表現
 数値、時間、場所、識別番号、識別名称、…
 オブジェクトのフィールド変数(インスタンス変数)とメソッドの引数
 ビジネスとして適切な値の範囲を定義する
 Rule (計算ロジックや判定ロジック)の置き場所
 Factを使う計算や判定をメソッドとして記述する
 Factと持つオブジェクトに、関連するロジックを集める
 Goal 知りたいこと(計算結果、判定結果)の表現手段
 知りたいことを表現した型(値の種類)を設計する
 メソッドの返す型として使う
値オブジェクトの分類表
単一の値 from-to [ from-to, … ]
数
値
金額型
Amount, Money
金額範囲
x円以上 y円未満
金額範囲のコレクション
価格帯
数量型
Quantity, NumberOfXxx
数量範囲
m人以上 n人以下
数量範囲のコレクション
数量別割引率
時
間
日付型
DueDate, XxxDate
期間
開始日 - 終了日
期間のコレクション
シーズン
時刻型
HourTime, XxxTime
時間
開始時刻 – 終了時刻
時間のコレクション
時間帯
空
間
地点型
Point
接続
Path:出発点 – 到達点
接続のコレクション
Route [Path,…]
地域型
Area, Zone
-
地域のコレクション
階層、fuzzy、重複、…
参考: アナリシスパターン 基本型
値オブジェクトの効果
 値オブジェクト=ビジネスに特化した値の種類
 動かすだけなら、プログラミング言語が提供する汎用的な型だけでよい
 ビジネスに特化した型
 プログラムが、ビジネスルールの記述そのものになる
 値の種類ごとにビジネスロジックの計算判定の記述が一か所にまとまる
 あちこちに重複しなくなる
 ビジネスルールの変更にかかわるソフトウェアの変更が楽で安全になる
値オブジェクトの設計
計算の種類を特定する
計算の種類 説明、メソッド例 結果の型
等値判定 isEqual( other ) , notEqual( other ) boolean / enum
大小判定 greaterThan( other ), lessThan( other ), … boolean / enum
加算・減算 同じ型同士の計算 同じ型
乗算 同じ型同士の乗算は意味がないことが多い 別の数値型
除算 同じ型の除算と、異なる型の除算では、意味が異なる 別の数値型
境界 Max, Min の存在 同じ型(の固定値)
列挙 prev(), next() が可能な集合 (循環が可/不可) 同じ型
文字列表現 その値の標準的な文字列表現 toString() 文字列
文字列からの生成 標準的な文字列表現からのオブジェクト生成 parse() 同じ型
どんな計算が必要か、値の種類ごとに検討する
計算の意図を、結果の型とメソッド名で説明する
値オブジェクトを使って変更を安全にする
契約による設計
契約による設計
変更を楽で安全にするための設計技法
事前条件(クラスを使う側の責任)
事後条件(計算を提供するクラスの責任)
assert による表明 型による表明
暗黙のビジネスルールの明文化につながる
値の範囲と計算の種類を限定する→動作が安定する
出典:バートランドメイヤー オブジェクト指向入門
enumを使った区分ごとのロジックの整理
区分ごとのロジックを扱う
区分ごとの条件分岐が複雑さの大きな原因
enumは区分ごとのロジックを整理する強力な手段
enumを使うと区分体系の問題の発見と改善が進む
区分を列挙しただけのenumを作る
区分ごとの定数をenumのフィールド変数に移動
区分ごとの計算や判定のロジックをenumのメソッドに移動
コードがゆがむ(フィールド変数やメソッドの一貫性が崩れる)
区分のリファクタリング(区分の分解、再定義)
ビジネスルール記述のわかりやすさにブレークスルーが起きる
コレクションのカプセル化
コレクション操作の問題と改善
問題
あちこちにコレクションを操作する類似の記述が分散
バグが紛れ込みやすい(不整合が起きやすい)
コレクション操作の手続きは、ビジネスの関心事ではない
改善策
目的別のコレクション型を独自につくる
コレクション操作のロジックをそのクラスに集める
コレクション操作の詳細を隠蔽する
コレクションのカプセル化の効果
コレクション操作がちらばっていたコードのぐちゃぐちゃ感が消える
コレクション操作を集めることで、リファクタリングがやりやすくなる
コレクション操作の整合性と一貫性が向上する
コレクション操作という技術手段が隠蔽され
クラス名とメソッド名でビジネスの関心事が前面に登場する
型指向のプログラミング
具体例
時給ベースの給与計算
https://github.com/system-sekkei/isolating-the-domain
attendance.Attendance 勤怠
attendance.AttendanceStatus 勤怠状況
attendance.Recorded 勤務記録有無
attendance.TimeRecords 勤務実績一覧
attendance.TotalWorkTime 総勤務時間
attendance.WorkMonth 勤務月
contract.Contract 従業員契約
contract.Contracts 従業員契約一覧
contract.ContractStartingDate 契約開始日
contract.ContractStatus 契約状態
contract.ContractWage 契約給与
contract.ContractWages 契約給与一覧
contract.HourlyWage 時給
contract.MidnightHourlyExtraWage 深夜時給割増額
contract.OverTimeHourlyExtraWage 深夜時給割増額
contract.WageCondition 給与条件
employee.ContractingEmployees 契約中従業員一覧
employee.Employee 従業員
employee.EmployeeNumber 従業員番号
employee.MailAddress メールアドレス
employee.Name 氏名
employee.PhoneNumber 電話番号
legislation.DailyOvertimeWork 時間外労働
legislation.ExtraPayRate 割増率(%)
legislation.Midnight 深夜
legislation.MidnightExtraRate 深夜割増率
legislation.OverTimeExtraRate 時間外割増率
payroll.PaymentAmount 支払い金額
payroll.PaymentWorkTime 支払い対象時間
payroll.Payroll 給与
payroll.Payrolls 給与一覧
payroll.PayrollStatus 給与ステータス
timerecord.ActualWorkTime 勤務時間実績
timerecord.bindingtime.BindingTime 拘束時間
timerecord.bindingtime.DaytimeBindingTime 日中拘束時間
timerecord.bindingtime.MidnightBindingTime 深夜拘束時間
timerecord.breaktime.BreakTime 休憩時間合計
timerecord.breaktime.DaytimeBreakTime 日中休憩時間
timerecord.breaktime.MidnightBreakTime 休憩時間(深夜)
timerecord.DaytimeWorkTime 日中勤務時間
timerecord.EndTime 勤務終了時刻
timerecord.MidnightWorkTime 深夜勤務時間
timerecord.OverWorkTime 時間外勤務時間
timerecord.StartTime 勤務開始時刻
timerecord.TimeRange 勤務の開始と終了
timerecord.TimeRecord 勤務実績
timerecord.WorkDate 勤務日付
timerecord.WorkTime 勤務時間
amount.Amount 金額
amount.Percentage 率(割増や税などの金額に掛けられるもの)
amount.RoundingMode 端数処理
date.Date 日付
date.DayOfWeek 曜日
date.Month 月
date.Year 年
date.YearMonth 年月
time.ClockTime 時刻を時分単位で表す
time.ClockTimeRange 開始時刻と終了時刻を表現する(時刻間の時間間隔を返す
time.Hour 時間(数)
time.HourAndMinute x時間y分
time.Minute 分(数)
time.QuarterHour 15分単位の時間
time.QuarterRoundClockTime 15分単位の時刻
time.QuarterRoundClockTimeRange 15分単位の時刻
給与計算に関するFact-Rule-Goalを表現したクラス群=ビジネスルール用語集
(ソースコードから自動生成したドキュメント)
60種類の独自の型を
9つのパッケージで整理
パッケージ構造が
ビジネスルールの概要説明になっている
(ソースコードから自動生成したパッケージ図)
区分ごとのロジックの整理
区分に依存するロジックの視覚化
(ソースコードから自動生成した区分の関連図)
ソフトウェアの複雑さの大きな原因である、区分ごと
のロジックをenumで整理
enumを参照するクラスを特定し、区分構造の影響範
囲を視覚化する
型指向のプログラミングの効果
画面、テーブル、APIフォーマットの見方が変わる
データ項目のフラットな集り → 計算元データと計算結果の集合体
「計算」という意味ごとの項目グループに分かれて見えるようになる
ビジネスルールの計算・判定に分解して解釈するようになる
ビジネスの関心事と開発者の関心事の単位(モジュール構造)が一致する
ビジネスルールの分離
型指向のプログラミング
コードの読みやすさに投資する
全体を見渡す習慣
変更を楽で安全にする4つの根底技法
従来のモジュール設計と可読性
(手続き的なプログラミング)
コードの読みやすさに投資する動機に欠ける
モジュール構造が固定なので
クラス名、パッケージ名、メソッド名を考える機会が少ない
引数名と変数名だけ工夫しても、あまり効果がない
動けばOK症候群や力ずくプログラミングでは
読みやすさへの関心は弱い
ビジネスルールを型で記述するプログラミング
コードの読みやすさに投資する効果が大きくなる
パッケージ名、クラス名、メソッド名がそのままビジネスルールの記述の語彙になる
名前のわかりやすさの改善が、コードの読みやすさに直結する
型を使う側に型名の効果が波及する
型名がいいかげんだとわかりにくさや不自然さがきわだつようになる
型名の改善の before/afterの差が歴然となる
改善効果を実感できる機会が増え
読みやすさの改善に自然に取り組むようになる
ビジネスルールの分離
型指向のプログラミング
コードの読みやすさに投資する
全体を見渡す習慣
変更を楽で安全にする4つの根底技法
全体を見渡す習慣
従来のモジュール構造では、全体を見る機会が少ない
その結果、コードの重複がはびこる
ビジネスルールを型を使って記述する設計スタイルだと、
どのロジックがどこを使われているかがわかりやすくなる
全体を意識したモジュール構造や名前の改善が習慣になる
パッケージ間の依存関係が見えてこない
ツリー構造を眺めても、あまり有用な情報がない
あちこちに同じロジックが重複して記述される
それに気が付かない
ツリー構造
(ソースコードから自動生成したパッケージツリー図)
ビジネスルール層の型名を使って、アプリケーション全体が型のネットワーク構造になる
どこに何が書いてあるか、どこの変更がどこに影響するか/しないかが、構造的にはっきりする
IDEのfind Usageや定義場所へ移動で、日常的に全体の関連性を意識するようになる
型のネットワーク構造
(ソースコードから自動生成した型の関連図)
ビジネスルールの分離
型指向のプログラミング
コードの読みやすさに投資する
全体を見渡す習慣
変更を楽で安全にする4つの根底技法
分析設計のアプローチ
ビジネスルール層
アプリケーション層
ビジネスルール層の分析設計のアプローチ
ビジネスルールの3つの源泉
価値提供の約束と支払いの約束
ビジネス活動の連鎖/契約の連鎖
競争優位の獲得策/競争劣位の防止策
契約
バリュー
チェーン
事業運営
ポリシー
約束
何を(区分)
どのくらい(数量)
いつ(日時)
いくらで(金額)
誰に(区分)
約束の履行の監視と促進の決め事
いつ何が起きるべきか(イベント区分、状態区分)
起きたことの検知
起きなかったことの検知
起きた場合のアクション
起きなかった場合のアクション
約束違反の扱いの決め事
約束のキャンセル(可否の判断、可能な場合の補償)
価値を提供できなかった時のルール(返品、返金、…)
対価の支払いができなかった時のルール(ペナルティ、…)
ビジネスルール発見の着眼点
金額の計算
数量の計算
時点や期間の計算
場所や経路の計算
それらに影響する分類軸(区分)
顧客、商品特性、取引種類、支払い方法、配送方法、…
在庫特性、進捗マイルストーン、担当、時間帯、曜日、季節、地域、….
アプリケーション層の分析設計技法
ビジネスルールの記述を独立させる
プレゼンテーション層の
モジュール群
アプリケーション層の
モジュール群
データソース層の
モジュール群
ビジネスルールを
記述したモジュール群
利用する
アプリケーション層の複雑さ
ビジネスルールの記述を、ビジネスロジック層に移動する
理論的にはアプリケーション層はとてもシンプルになる
現実はアプリケーション層に複雑なロジックが残りやすい
アプリケーション層の複雑さの分析と整理 (VETRO, Saga)
VETRO分析
VETRO 分析とは?
ビジネストランザクションをビジネスメッセージの処理としてとらえる
メッセージ処理を5種類のアクション(VETRO)に分解してみる
アクションごとに、どのルールをどのタイミングで適用するか検討する
VETRO
Validation
妥当性検証
Enrich
情報付加
Translate
情報導出
Routing
分岐判定
Operation
通知/記録ビジネス
メッセージ
出典: Camel Design Patterns
非同期メッセージングを使った EIP: Enterprise Integration Patternsの応用パターン
VETRO
ビジネス
メッセージ
Event 通知、Document送付
Query 問い合わせ、Command 指示
Validation
妥当性検証
メッセージ内容の妥当性を検証する
データ形式、必須属性、値範囲、…
Enrich
情報付加
メッセージに含まれたIDなどから、関連する情報
を収集するルール(ex. 顧客ID->顧客購買履歴)
Translate
情報導出
付加された情報を元に、新たな情報を導出する
ルール (ex. 購買履歴 → 顧客ランク )
Routing
分岐判定
導出された情報を元に、適切なオペレーションに
分岐させるルール ( ex. 顧客ランクごとの対応 )
Operation
通知/記録
通知ルール:誰に何を通知すべきか?
記録ルール:どこに何を記録すべき?
Saga
複合トランザクションに分解する
Sagaとは?
③が不成立だった場合、①と②にキャンセル処理を実行する
という、さまざまな状況とその対応方法(undo)の物語を用意する
①②③を、独立して、順不同で実行する (それぞれの物語)
三つともOKであれば、それで完了(Happy Goal)
独立したトランザクション A
独立したトランザクション B
独立したトランザクション C
ビジネス
メッセージ
コーディ
ネータ
ひとつの大きなトランザクション → 独立した複数の小さなトランザクションに分割
Sagaとは?
 独立したトランザクションのコミット
 個々のトランザクションは独立して確定する(できる)
 undo の仕組み
 どこかで不都合な状況が発生した場合、キャンセル処理など適切なカウン
タートランザクションを実行する仕組みを用意する
 ビジネスレベルでの代替アクションの分析と実装
 自動的なundo以外に、人間系の代替プロセスや取消プロセスの実行に引き
継ぐパターンも選択肢
 その場合の支援機能を用意する
まとめ
よい設計とは?
変更が楽で安全であること
変更が
楽で安全
開発スコープ
開発スピード
性能問題
ビジネス要求
開発費用
開発の労力
セキュリティ
対策
安定運用
操作性
機能追加
データ管理 外部連携
バグ対応
個人情報保護
ビジネスルールの分離
型指向のプログラミング
コードの読みやすさに投資する
全体を見渡す習慣
変更を楽で安全にする4つの根底技法
ビジネスルールの3つの源泉
価値提供の約束と支払いの約束
ビジネス活動の連鎖/契約の連鎖
競争優位の獲得策/競争劣位の防止策
契約
バリュー
チェーン
事業運営
ポリシー
Validation
妥当性検証
Enrich
情報付加
Translate
情報導出
Routing
分岐判定
Operation
通知/記録ビジネス
メッセージ
独立したトランザクション A
独立したトランザクション B
独立したトランザクション C
ビジネス
メッセージ
コーディ
ネータ
VETRO
Saga
アプリケーション層の分析設計
アジャイルなソフトウェア設計の学び方
参考書籍
コードを使ったワークショップなど
 リファクタリングの1stサンプルを使った体験学習
 サンプルアプリケーション(時給ベースの給与計算)の解説
 型指向のプログラミングの体験学習
 ビジネスルールの分析設計の体験学習

More Related Content

What's hot

ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったことドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと増田 亨
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門増田 亨
 
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装までドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで増田 亨
 
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1  ドメイン駆動設計の基本を理解する3週連続DDDその1  ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する増田 亨
 
ドメイン駆動設計 思えば遠くにきたもんだ
ドメイン駆動設計 思えば遠くにきたもんだドメイン駆動設計 思えば遠くにきたもんだ
ドメイン駆動設計 思えば遠くにきたもんだ増田 亨
 
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?実践的な設計って、なんだろう?
実践的な設計って、なんだろう?増田 亨
 
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解するドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する増田 亨
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計増田 亨
 
毎日が越境だ!
毎日が越境だ!毎日が越境だ!
毎日が越境だ!増田 亨
 
ドメイン駆動設計をゲーム開発に活かす
ドメイン駆動設計をゲーム開発に活かすドメイン駆動設計をゲーム開発に活かす
ドメイン駆動設計をゲーム開発に活かす増田 亨
 
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由増田 亨
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMPYusuke Kagata
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方増田 亨
 
ソフトウェアテスト入門
ソフトウェアテスト入門ソフトウェアテスト入門
ソフトウェアテスト入門Preferred Networks
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?Yoshitaka Kawashima
 
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8Koichiro Matsuoka
 
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方増田 亨
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説増田 亨
 
短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術Takafumi ONAKA
 

What's hot (20)

ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったことドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
 
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装までドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
 
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1  ドメイン駆動設計の基本を理解する3週連続DDDその1  ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
 
ドメイン駆動設計 思えば遠くにきたもんだ
ドメイン駆動設計 思えば遠くにきたもんだドメイン駆動設計 思えば遠くにきたもんだ
ドメイン駆動設計 思えば遠くにきたもんだ
 
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
 
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解するドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
 
毎日が越境だ!
毎日が越境だ!毎日が越境だ!
毎日が越境だ!
 
ドメイン駆動設計をゲーム開発に活かす
ドメイン駆動設計をゲーム開発に活かすドメイン駆動設計をゲーム開発に活かす
ドメイン駆動設計をゲーム開発に活かす
 
私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由私がドメイン駆動設計をやる理由
私がドメイン駆動設計をやる理由
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMP
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
 
ソフトウェアテスト入門
ソフトウェアテスト入門ソフトウェアテスト入門
ソフトウェアテスト入門
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
 
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
 
世界最強のソフトウェアアーキテクト
世界最強のソフトウェアアーキテクト世界最強のソフトウェアアーキテクト
世界最強のソフトウェアアーキテクト
 
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
 
短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術
 

Similar to アジャイルなソフトウェア設計を目指して

アジャイル実践における開発環境の変化〜要求の捉え方、プロジェクト運営、ツール支援
アジャイル実践における開発環境の変化〜要求の捉え方、プロジェクト運営、ツール支援アジャイル実践における開発環境の変化〜要求の捉え方、プロジェクト運営、ツール支援
アジャイル実践における開発環境の変化〜要求の捉え方、プロジェクト運営、ツール支援智治 長沢
 
20161213_FinTech時代に求められるDB開発とセキュリティ by 株式会社インサイトテクノロジー 阿部健一
20161213_FinTech時代に求められるDB開発とセキュリティ by 株式会社インサイトテクノロジー 阿部健一20161213_FinTech時代に求められるDB開発とセキュリティ by 株式会社インサイトテクノロジー 阿部健一
20161213_FinTech時代に求められるDB開発とセキュリティ by 株式会社インサイトテクノロジー 阿部健一Insight Technology, Inc.
 
DevOps時代の開発環境と現場体験 [#cmdevio2015]
DevOps時代の開発環境と現場体験 [#cmdevio2015]DevOps時代の開発環境と現場体験 [#cmdevio2015]
DevOps時代の開発環境と現場体験 [#cmdevio2015]智治 長沢
 
20160927_守るべきは、大量の情報資産を管理するデータベース! ~ユーザ事例から見るデータベースのセキュリティ対策~ by 株式会社インサイトテクノ...
20160927_守るべきは、大量の情報資産を管理するデータベース! ~ユーザ事例から見るデータベースのセキュリティ対策~ by 株式会社インサイトテクノ...20160927_守るべきは、大量の情報資産を管理するデータベース! ~ユーザ事例から見るデータベースのセキュリティ対策~ by 株式会社インサイトテクノ...
20160927_守るべきは、大量の情報資産を管理するデータベース! ~ユーザ事例から見るデータベースのセキュリティ対策~ by 株式会社インサイトテクノ...Insight Technology, Inc.
 
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operationYasuhiro Araki, Ph.D
 
高信頼性を確保するソフトウェア開発手法と実践 -組込み製品の潜在的価値を今以上に高めるために-
高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために-高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために-
高信頼性を確保するソフトウェア開発手法と実践 -組込み製品の潜在的価値を今以上に高めるために-Yoshio SAKAI
 
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOpsJAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps智治 長沢
 
なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)
なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)
なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)Masaya Tahara
 
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsakaビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka智治 長沢
 
【17-D-6】「ソフトウェアの収益増大のためのセキュリティソリューション」小池康幸氏
【17-D-6】「ソフトウェアの収益増大のためのセキュリティソリューション」小池康幸氏【17-D-6】「ソフトウェアの収益増大のためのセキュリティソリューション」小池康幸氏
【17-D-6】「ソフトウェアの収益増大のためのセキュリティソリューション」小池康幸氏Developers Summit
 
サービス開発における工程
サービス開発における工程サービス開発における工程
サービス開発における工程Hidetoshi Mori
 
Timソリューションのご紹介 140319
Timソリューションのご紹介 140319 Timソリューションのご紹介 140319
Timソリューションのご紹介 140319 Rie Arai
 
Timソリューションのご紹介 140320
Timソリューションのご紹介 140320 Timソリューションのご紹介 140320
Timソリューションのご紹介 140320 Rie Arai
 
Timソリューションのご紹介 140319
Timソリューションのご紹介 140319 Timソリューションのご紹介 140319
Timソリューションのご紹介 140319 Rie Arai
 
JaSST'13 Kansai 継続的フィードバックによる品質運営
JaSST'13 Kansai 継続的フィードバックによる品質運営JaSST'13 Kansai 継続的フィードバックによる品質運営
JaSST'13 Kansai 継続的フィードバックによる品質運営智治 長沢
 
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来Yoshihito Kuranuki
 
~ Build と言えば やっぱり Developer! ~ Microsoft 開発ツール最新アップデート
~ Build と言えば やっぱり Developer! ~ Microsoft 開発ツール最新アップデート~ Build と言えば やっぱり Developer! ~ Microsoft 開発ツール最新アップデート
~ Build と言えば やっぱり Developer! ~ Microsoft 開発ツール最新アップデートAkira Inoue
 
Sequent Asia IT Refined Japanese Presentation
Sequent Asia IT Refined Japanese PresentationSequent Asia IT Refined Japanese Presentation
Sequent Asia IT Refined Japanese Presentationsaiitweb
 
A16_VB でクラサバシステムの開発をしていた平凡なチームが、どのようにクラウドネイティブプロダクト開発にシフトしアジャイル開発を進めることができたのか...
A16_VB でクラサバシステムの開発をしていた平凡なチームが、どのようにクラウドネイティブプロダクト開発にシフトしアジャイル開発を進めることができたのか...A16_VB でクラサバシステムの開発をしていた平凡なチームが、どのようにクラウドネイティブプロダクト開発にシフトしアジャイル開発を進めることができたのか...
A16_VB でクラサバシステムの開発をしていた平凡なチームが、どのようにクラウドネイティブプロダクト開発にシフトしアジャイル開発を進めることができたのか...日本マイクロソフト株式会社
 

Similar to アジャイルなソフトウェア設計を目指して (20)

アジャイル実践における開発環境の変化〜要求の捉え方、プロジェクト運営、ツール支援
アジャイル実践における開発環境の変化〜要求の捉え方、プロジェクト運営、ツール支援アジャイル実践における開発環境の変化〜要求の捉え方、プロジェクト運営、ツール支援
アジャイル実践における開発環境の変化〜要求の捉え方、プロジェクト運営、ツール支援
 
20161213_FinTech時代に求められるDB開発とセキュリティ by 株式会社インサイトテクノロジー 阿部健一
20161213_FinTech時代に求められるDB開発とセキュリティ by 株式会社インサイトテクノロジー 阿部健一20161213_FinTech時代に求められるDB開発とセキュリティ by 株式会社インサイトテクノロジー 阿部健一
20161213_FinTech時代に求められるDB開発とセキュリティ by 株式会社インサイトテクノロジー 阿部健一
 
Enterprise DevOps
Enterprise DevOpsEnterprise DevOps
Enterprise DevOps
 
DevOps時代の開発環境と現場体験 [#cmdevio2015]
DevOps時代の開発環境と現場体験 [#cmdevio2015]DevOps時代の開発環境と現場体験 [#cmdevio2015]
DevOps時代の開発環境と現場体験 [#cmdevio2015]
 
20160927_守るべきは、大量の情報資産を管理するデータベース! ~ユーザ事例から見るデータベースのセキュリティ対策~ by 株式会社インサイトテクノ...
20160927_守るべきは、大量の情報資産を管理するデータベース! ~ユーザ事例から見るデータベースのセキュリティ対策~ by 株式会社インサイトテクノ...20160927_守るべきは、大量の情報資産を管理するデータベース! ~ユーザ事例から見るデータベースのセキュリティ対策~ by 株式会社インサイトテクノ...
20160927_守るべきは、大量の情報資産を管理するデータベース! ~ユーザ事例から見るデータベースのセキュリティ対策~ by 株式会社インサイトテクノ...
 
20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation20140717 awssummit2014-cloud-operation
20140717 awssummit2014-cloud-operation
 
高信頼性を確保するソフトウェア開発手法と実践 -組込み製品の潜在的価値を今以上に高めるために-
高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために-高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために-
高信頼性を確保するソフトウェア開発手法と実践 -組込み製品の潜在的価値を今以上に高めるために-
 
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOpsJAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
JAWS FESTA Kansai 2013 | ビジネスに貢献する戦略的なITのためのDevOps
 
なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)
なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)
なぜあなたのプロジェクトのDevSecOpsは形骸化するのか(CloudNative Security Conference 2022)
 
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsakaビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
ビジネスとソフトウェア開発現場の架け橋 〜 なぜアジャイル? #AgileJapanOsaka
 
【17-D-6】「ソフトウェアの収益増大のためのセキュリティソリューション」小池康幸氏
【17-D-6】「ソフトウェアの収益増大のためのセキュリティソリューション」小池康幸氏【17-D-6】「ソフトウェアの収益増大のためのセキュリティソリューション」小池康幸氏
【17-D-6】「ソフトウェアの収益増大のためのセキュリティソリューション」小池康幸氏
 
サービス開発における工程
サービス開発における工程サービス開発における工程
サービス開発における工程
 
Timソリューションのご紹介 140319
Timソリューションのご紹介 140319 Timソリューションのご紹介 140319
Timソリューションのご紹介 140319
 
Timソリューションのご紹介 140320
Timソリューションのご紹介 140320 Timソリューションのご紹介 140320
Timソリューションのご紹介 140320
 
Timソリューションのご紹介 140319
Timソリューションのご紹介 140319 Timソリューションのご紹介 140319
Timソリューションのご紹介 140319
 
JaSST'13 Kansai 継続的フィードバックによる品質運営
JaSST'13 Kansai 継続的フィードバックによる品質運営JaSST'13 Kansai 継続的フィードバックによる品質運営
JaSST'13 Kansai 継続的フィードバックによる品質運営
 
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
 
~ Build と言えば やっぱり Developer! ~ Microsoft 開発ツール最新アップデート
~ Build と言えば やっぱり Developer! ~ Microsoft 開発ツール最新アップデート~ Build と言えば やっぱり Developer! ~ Microsoft 開発ツール最新アップデート
~ Build と言えば やっぱり Developer! ~ Microsoft 開発ツール最新アップデート
 
Sequent Asia IT Refined Japanese Presentation
Sequent Asia IT Refined Japanese PresentationSequent Asia IT Refined Japanese Presentation
Sequent Asia IT Refined Japanese Presentation
 
A16_VB でクラサバシステムの開発をしていた平凡なチームが、どのようにクラウドネイティブプロダクト開発にシフトしアジャイル開発を進めることができたのか...
A16_VB でクラサバシステムの開発をしていた平凡なチームが、どのようにクラウドネイティブプロダクト開発にシフトしアジャイル開発を進めることができたのか...A16_VB でクラサバシステムの開発をしていた平凡なチームが、どのようにクラウドネイティブプロダクト開発にシフトしアジャイル開発を進めることができたのか...
A16_VB でクラサバシステムの開発をしていた平凡なチームが、どのようにクラウドネイティブプロダクト開発にシフトしアジャイル開発を進めることができたのか...
 

More from 増田 亨

事業活動モデル・システム機能モデル・ビジネスロジックの記述
事業活動モデル・システム機能モデル・ビジネスロジックの記述事業活動モデル・システム機能モデル・ビジネスロジックの記述
事業活動モデル・システム機能モデル・ビジネスロジックの記述増田 亨
 
オブジェクト指向プログラミングの現在・過去・未来
オブジェクト指向プログラミングの現在・過去・未来オブジェクト指向プログラミングの現在・過去・未来
オブジェクト指向プログラミングの現在・過去・未来増田 亨
 
ドメイン駆動設計 コアドメインを語り合ってみよう
ドメイン駆動設計 コアドメインを語り合ってみようドメイン駆動設計 コアドメインを語り合ってみよう
ドメイン駆動設計 コアドメインを語り合ってみよう増田 亨
 
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primerオブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer増田 亨
 
ドメイン駆動設計という設計スタイル
ドメイン駆動設計という設計スタイルドメイン駆動設計という設計スタイル
ドメイン駆動設計という設計スタイル増田 亨
 
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチレガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ増田 亨
 
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチマイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ増田 亨
 
ビジネスルールの複雑さに立ち向かう
ビジネスルールの複雑さに立ち向かうビジネスルールの複雑さに立ち向かう
ビジネスルールの複雑さに立ち向かう増田 亨
 
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かうソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう増田 亨
 
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門増田 亨
 
DDD sample code explained in Java
DDD sample code explained in JavaDDD sample code explained in Java
DDD sample code explained in Java増田 亨
 
SoR 2.0 summary
SoR 2.0 summarySoR 2.0 summary
SoR 2.0 summary増田 亨
 
SoR 2.0 基幹システムの再定義と再構築
SoR 2.0 基幹システムの再定義と再構築SoR 2.0 基幹システムの再定義と再構築
SoR 2.0 基幹システムの再定義と再構築増田 亨
 
ドメイン駆動設計とは何か 【入門編】
ドメイン駆動設計とは何か 【入門編】ドメイン駆動設計とは何か 【入門編】
ドメイン駆動設計とは何か 【入門編】増田 亨
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方増田 亨
 
越境する情シス:進化可能なアーキテクチャを手に入れる
越境する情シス:進化可能なアーキテクチャを手に入れる越境する情シス:進化可能なアーキテクチャを手に入れる
越境する情シス:進化可能なアーキテクチャを手に入れる増田 亨
 
ドメイン駆動設計の基礎知識:設計のスタイル、開発のスタイル
ドメイン駆動設計の基礎知識:設計のスタイル、開発のスタイルドメイン駆動設計の基礎知識:設計のスタイル、開発のスタイル
ドメイン駆動設計の基礎知識:設計のスタイル、開発のスタイル増田 亨
 
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則現場で役立つシステム設計の原則
現場で役立つシステム設計の原則増田 亨
 
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則現場で役立つシステム設計の原則
現場で役立つシステム設計の原則増田 亨
 

More from 増田 亨 (19)

事業活動モデル・システム機能モデル・ビジネスロジックの記述
事業活動モデル・システム機能モデル・ビジネスロジックの記述事業活動モデル・システム機能モデル・ビジネスロジックの記述
事業活動モデル・システム機能モデル・ビジネスロジックの記述
 
オブジェクト指向プログラミングの現在・過去・未来
オブジェクト指向プログラミングの現在・過去・未来オブジェクト指向プログラミングの現在・過去・未来
オブジェクト指向プログラミングの現在・過去・未来
 
ドメイン駆動設計 コアドメインを語り合ってみよう
ドメイン駆動設計 コアドメインを語り合ってみようドメイン駆動設計 コアドメインを語り合ってみよう
ドメイン駆動設計 コアドメインを語り合ってみよう
 
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primerオブジェクト指向プログラミング入門 -- Java object-oriented programming primer
オブジェクト指向プログラミング入門 -- Java object-oriented programming primer
 
ドメイン駆動設計という設計スタイル
ドメイン駆動設計という設計スタイルドメイン駆動設計という設計スタイル
ドメイン駆動設計という設計スタイル
 
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチレガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
レガシーコードの複雑さに立ち向かう~ドメイン駆動設計のアプローチ
 
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチマイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
 
ビジネスルールの複雑さに立ち向かう
ビジネスルールの複雑さに立ち向かうビジネスルールの複雑さに立ち向かう
ビジネスルールの複雑さに立ち向かう
 
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かうソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
 
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
 
DDD sample code explained in Java
DDD sample code explained in JavaDDD sample code explained in Java
DDD sample code explained in Java
 
SoR 2.0 summary
SoR 2.0 summarySoR 2.0 summary
SoR 2.0 summary
 
SoR 2.0 基幹システムの再定義と再構築
SoR 2.0 基幹システムの再定義と再構築SoR 2.0 基幹システムの再定義と再構築
SoR 2.0 基幹システムの再定義と再構築
 
ドメイン駆動設計とは何か 【入門編】
ドメイン駆動設計とは何か 【入門編】ドメイン駆動設計とは何か 【入門編】
ドメイン駆動設計とは何か 【入門編】
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
 
越境する情シス:進化可能なアーキテクチャを手に入れる
越境する情シス:進化可能なアーキテクチャを手に入れる越境する情シス:進化可能なアーキテクチャを手に入れる
越境する情シス:進化可能なアーキテクチャを手に入れる
 
ドメイン駆動設計の基礎知識:設計のスタイル、開発のスタイル
ドメイン駆動設計の基礎知識:設計のスタイル、開発のスタイルドメイン駆動設計の基礎知識:設計のスタイル、開発のスタイル
ドメイン駆動設計の基礎知識:設計のスタイル、開発のスタイル
 
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
 
現場で役立つシステム設計の原則
現場で役立つシステム設計の原則現場で役立つシステム設計の原則
現場で役立つシステム設計の原則
 

アジャイルなソフトウェア設計を目指して