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

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

BASE, Inc. で社内勉強会を開くときに考えた、僕らの学習アプローチと勉強会設計について話しました。

RDRA1.0とDDDを組み合わせた経験から以下の観点 について解説 1) いきなりドメインモデルを考えられるか 2) ドメインモデルの周辺環境を探索する

仙台で行われたレッツゴーデベロッパーZERO ONEで登壇した資料です。

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

はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は

Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！ コラボカンファレンス に登壇させていただいたのでで、その際の資料です。 また、当日sli.doでたくさんのご質問をいただいたので、まとめてお答えします。 発表資料 DDDのモデリングとは何なのか、 そしてどうコードに落とすのか from Koichiro Matsuoka www.slideshare.net もっと詳しく知りたい方は この発表資料の内容を、さらに詳しく解説した書籍を出しました！ little-hands.booth.pm 初めてDDDを学ぶ方、もしくは実際に着手して難しさにぶつかっている方向けの書籍になっています。 迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 この本の「第2章

10. 設計スタイルの違い 2019/8/31 10 関心 モジュール構造 ２０：８０ 入出力 ドメインロジック ビジネスルールに基づく計算と判断のロジック画面、テーブル、Web API トランザクションスクリプト 画面やデータに注目して、入出力手続きを構造化 値の種類に注目して、独自の型を定義 ドメインオブジェクトモデル 11. 設計スタイルの違い 2019/8/31 11 関心 モジュール構造 ２０：８０ 入出力 ドメインロジック ビジネスルールに基づく計算と判断のロジック画面、テーブル、Web API トランザクションスクリプト ドメインロジックの設計と実装が アプリケーション全体の構造を左右する 画面やデータに注目して、入出力手続きを構造化 値の種類に注目して、独自の型でロジックを構造化 入出力の設計と実装が アプリケーション全体の構造を左右する ドメインオブジェクトモデル

3. オブジェクト指向設計の 考え方とやり方 オブジェクト指向エクササイズ ９つのルール モジュール性 ５つの基準 抽象データ型 契約による設計 コードのいやな臭い その改善策１章 ドメインを学ぶ ２章 言葉を使う ３章 モデルと実装を結びつける ４章 ドメインを隔離する ５章 モデルを表現する部品 １０章 しなやかな設計 ４冊とも、想定読者はオブジェクト指向でコードを書く人 それぞれが関連している 今日は実践例として紹介してみたい

吉祥寺pm#19 での LT 資料です。

はじめに DDDの実装パターンとして、エンティティと値オブジェクトというものがあります。 ドメイン駆動一般に複雑な抽象論が多い中で、コードに近く一番イメージがつきやすいコード事例として出てくるため、ここだけは何となくわかるぞ！という方もいらっしゃるのではないでしょうか。 今日はこちらの概要とそれぞれの使い道について書きたいと思います。 先にざっくりイメージ図をお伝えすると、こういう図を使って解説します。 何の目的で作るのか？ ドメイン駆動設計は何を解決しようとしているのか こちらの記事で、ドメイン駆動設計のアプローチは以下の2ステップがあるということを書きました。 ドメインの問題を解決するための抽象的なモデルを作る. モデルをソフトウェア(コード)に落とし込む ※ ドメイン＝ソフトウェアを適用して問題解決しようとする領域 DDDでは、このStep2の モデルをコードで表現するためのパターン

DDDの文脈の中で、 「ドメイン知識とユースケース(≒アプリケーションの知識)は何が違うのか？」 という疑問がよく持たれます。 この記事ではその違いを説明し、DDDのコードにどう反映するかを書きます。 あるToDoアプリの仕様 事例として、ToDoアプリの話をします。 「仕様を決める」と言ったとき、以下のように箇条書きで決めることがあると思います。(Jiraのようなチケット管理システムのチケット詳細として書いたりしますよね) ユーザー登録、非活性化ができる メールアドレスは重複登録できない タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる タスクは3回までしか延期ができない 非活性化されていないユーザーにアサインができる タスクを完了、アサインするとタスクレポートが作成される これはいわゆる「ビジネスロジック」と呼ばれて、3層レイヤーのアーキテクチャではBusine

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 DDDが、デザイン界隈で注目されだした「OOUX」という設計手法を吸収合併すると皆んながハッピーになるはず、という主にはUI設計のお話です。 OOUXとは Object-Oriented User eXperience の略で、端的に言うと、UIを設計する際「（ユーザのアクションでなく）オブジェクト視点で設計するとより直観的なUIが作れるよ」という手法 1です。考え方自体はOOPが提唱された時代から（OOUIという呼び名で）あったようなのですが 2、UX界隈では2016年頃から話題にのぼるようになりました。 このアドベントを見てい

命名スルこと日本語には漢語由来の熟語がいくつもありますが、日本人からするといくらか記号的に見えてしまうことがあります。とはいえ漢字の意味を知っているので読んで差し支えはないのですが、それらの字の間に「の」を挟みこむことで記号的な記述であった熟語を和語的な言葉として読むことができるようになります。例えば「命名」という熟語でそれを試すと「命の名（いのち の な）」という具合になりますが、「命名（スル）」という言葉を思い浮かべるよりかは「命の名（を付ける）」の方が、より一層にある概念に命を吹き込む行為であることが強調されるので、それがとても尊い行いであると改めて理解することができます。 命に名前を与える、あるいは名前を与えて命を吹き込む、すなわち命名スルという行いは、名付けによってその存在の意味性を明らかにすることなのだろうと考えられます。親が生まれた子にまず与えるのは名前です。名前を与えること

「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ）ので、2/3くらいにまとめました