要件定義・仕様化・実装の継ぎ目をなくす開発手法。 ビジネスロジックを軸に組み立てる。 値の種類（型）に注目してモジュール化するRead less

ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により

Aws Dev Day2021 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)

1995年まで：イノベータとアーリーアダプターの時代； 1995-2005 ：　オブジェクト指向ブームと混乱の始まり；　2005-2015 ：　さらなる混乱と収束の兆し；　2015- ; 現在の状況とこれからの２０年

前置き 『現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法』の著者の増田さんが、 ワークショップで使用する「JR 新幹線　料金ルールを実装してみよう」というサンプルコードをGitHubで公開されておりました。 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版 明日 12/14 の「現場でDDD ! 2nd」のワークショップで使う、サンプルコードです。 新幹線の運賃と特急料金の計算ルールを、値オブジェクトで表現してみよう、という内容。 イベントに参加されない方も、ぜひ、チャレンジしてみてください。https://t.co/LlLKA5h7Bt #genbadeDDD— 増田 亨． (@masuda220) 2019年12月13日

Javaで学ぶ、オブジェクト指向プログラミングの基礎知識。型とカプセル化が腹落ちすると、びっくりするくらいオブジェクト指向プログラミングがわかようになる／できるようになる

業務で扱う(最小)単位でデータとロジックをひとまとめにして整理する技法 ドメインモデルが実現する世界 どこに何のロジックが書いてあるか、(ソースを見るだけで)わかる 改修しやすいプログラム ドメインモデルで解決したい問題 どこに何のロジックが書いてあるかわからない問題 - わからないから適当に書く→適当に書くからわからない → わからないから・・・ - ある修正をしようと思っても、どこまでが影響範囲かわからない - 使用している箇所全grepして調査 - 同じような処理、分岐が重複してしまう これを解決したい。これだけを考える。 なぜ(今までのシステムは)改修は難しいのか 機能クラスと、データクラスをわけてしまうから そのデータクラスを呼べる箇所 = 業務ロジックがかけてしまう どこになにが書いてあるかわからなくなる 共通クラス、Utilクラスを作ってしまうから 誰でも呼べる = そのクラ

/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>

大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をそのまま「商品クラス」と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。

オブジェクト指向プログラミングを学ぶ オブジェクト指向プログラミングという言葉は、広い意味で使われている。 オブジェクト指向プログラミングをキーワードにすべての情報をかき集めて理解するというアプローチは現実には無理。 目に付いた重要そうなところを見繕って集めてみても、たぶん混乱するだけ。 この記事では、オブジェクト指向プログラミングのいろいろなアプローチの中で、 クラスを使って独自の「型」を定義するプログラミングスタイル 関連するデータとロジックをまとめて、小さな入れ物に格納する「カプセル化」を重視するプログラミングスタイル を学ぶための参考図書を紹介したい。 型とカプセル化に重点を置く設計スタイルがわかってくると、それとは異なるスタイル、異なる力点を置くアプローチとの違いが具体的にわかるようになってくる。*1 *2 まずは、オブジェクト指向プログラミングの中で、型・クラス・カプセル化に力

ドメイン駆動設計という設計スタイルドメイン駆動設計という 設計スタイル ギルドワークス 増田 亨 2019.8.31 レガシーをぶっつぶせ！ 現場でDDD #genbadeDDD これから話すこと 2019/8/31 2 設計スタイルの選択 ドメインロジックに焦点をあわせる 開発現場での実験結果と考察 設計スタイルの選択 32019/8/31 設計スタイルの三つの側面 2019/8/31 4 関心の分離のアプローチ モジュール構造の考え方 ２０：８０のとらえ方 設計スタイルの三つの側面 2019/8/31 5 関心の分離のアプローチ モジュール構造の考え方 ２０：８０のとらえ方 何と何を分けるか？ 何と何を一体にするか ソースコードをどう分割し、どう組み立てるか 80%に大きな影響を及ぼす20%はどこか 設計スタイルの違い 2019/8/31 6 関心 モジュール構造 ２０：８０ 設計スタ

きしださんの以下のツイート オブジェクト指向はこの20年だれも再定義せずみんな自分の思うオブジェクト指向を暗黙に仮定して適当に話してるだけなので、技術的な共通認識のもとの議論はほとんどできないんですよ。という話を「オブジェクト指向をきちんと使いたいあなたへ」の記事に書いたのだけど、そろそろ公開するか— きしだൠ(K8S(Kishidades)) (@kis) July 29, 2019 を読んで、そういえば、私が思うオブジェクト指向の定義、についてツイッター以外ではあまり語ったことがなかったなと思い返し、ちょっと記事にしてみることにしました。まず、結論からいうと、私はオブジェクト指向プログラミングとは サブタイピングを活用したプログラミング手法の総称 と考えています。ここで、クラス継承とかインタフェース継承とかダックタイピングとかではなく、単にサブタイピングであるのがポイントです。なお、型

19/07/24開催の「持続可能なプロダクト開発への取り組み　～メドピアとクラウドワークスの事例公開～」における、クラウドワークス側の登壇資料です。 https://connpass.com/event/136791/

ドメイン駆動設計でなぜ作るのか？ ドメイン駆動設計の考え方の核心 レガシーコードの改善にドメイン駆動設計が役に立つのか？ ドメイン駆動設計でレガシーコードに立ち向かった８つのステップ 振り返りと展望

ソフトウェア設計の学び方を考えるソフトウェア設計の 学び方を考える 2019年6月23日 ギルドワークス 増田 亨 DevLOVE X(10周年記念イベント) アジェンダ 1. 設計という課題 2. ソフトウェア設計の品質 3. 学習と成長 4. 設計の初歩を学ぶ 5. 設計の中級者への道 6. 設計の上級者への挑戦 2019/6/23 2 ソフトウェア設計という課題 2019/6/23 3 複雑さとの戦い 構成要素の数 構成要素間の関係 拡張と変更の繰り返し 2019/6/23 4 人間の知的能力の限界 構成要素の数 構成要素間の関係 拡張と変更の繰り返し 2019/6/23 5 ソフトウェア設計の品質 2019/6/23 6 構造と秩序 2019/6/23 7 時間とともに劣化する構造と秩序 2019/6/23 8 時間とともに進化する構造と秩序 2019/6/23 9 ソフトウェア設

BPStudy#141〜DDD(Domain Driven Design)実践の現場 (2019/05/29 19:30〜) を聴講したときに、増田さんの発表がとても勉強になったのでまとめてみます。 簡単なこの記事のまとめ DDDは「ソフトウェアの変更を安全に楽にする」ことが目的。振り切っている DDDは、反復プロセスであって設計して終わりではない 勉強には、増田さんの本を読んだあとに、エヴァンス本がおすすめ。ほかには教材(GitHubのコード)などが用意してあり誰でも参照できる エヴァンス本は読みづらいが、コツがわかれば読みやすい 増田さんの資料 ドメイン駆動設計の正しい歩き方 from 増田 亨 ドメイン駆動設計の正しい歩き方 DDDの目的 進化するソフトウェアを手に入れる 現実世界の変更に追従するソフトウェア 動くだけではないソフトウェア ソフトウェアの変更を安全に楽にする もちろん

ドメイン駆動設計でなぜ作るのか？ ドメイン駆動設計の考え方 ドメイン駆動設計を実践するための６つの問い 事例研究 ドメイン駆動設計を現場に導入する 体験的に学ぶ エヴァンス本をちゃんと読む

TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に JavaScriptプロジェクトでTypeScriptを導入する際には、“柔らかい”静的型付き言語とするのがおすすめです。藤吾郎（gfx）さんがまとめた「がんばらないTypeScript」のガイドラインです。 TypeScriptは、すべてのJavaScriptプロジェクトで採用する価値のある技術です。TypeScriptとこれに対応したエディタを導入することで、補完や型ベースの整合性のチェックにより、すべてのプロジェクトで生産性が上がります。またリファクタリングも容易になるので、長期あるいは大規模なプロジェクトでも品質を保ちやすくなります。 この記事では、TypeScriptについて最低限の知識とともに、サクッと（どちらかというと既存のプロジェクトに）導入するための

Good Stuff Happens in 1:1 Meetings: Why you need them and how to do them well