10. 学んだことをコードで表現する • ドメインの知識をコードで表現する基本スキル • 値オブジェクト、コレクションオブジェクト、区分オブジェクト • 識別オブジェクト、集約 • Repository, Factory • 知識の増加がコードに現れる • パッケージ名、クラス名、インタフェース名、メソッド名 • 洞察の深さがコードに現れる • パッケージの構造、オブジェクトの参照関係、… • コードレビュー：ドメインの学習成果のレビュー • パッケージ名、クラス名、インタフェース名、メソッド名、… • 参照関係／グルーピングの範囲 • コードで表現されたドメインの知識の量は？ 質は？ • コードでの知識表現に工夫の余地は？ 10 技術者はエクセルで知識を表現してはいけない

これが大変に評価の高い本で、邦訳が長らく待たれましたが、ようやく2011年に「エリック・エヴァンスのドメイン駆動設計」というタイトルで出版されました。 このドメイン駆動設計ですが、技術者の間ではしばしばDDDと呼ばれます。 これらのパターンのうち必要なものを状況に応じて適用することによって、オブジェクト指向が本来持っている、再利用性や保守性といった利点を最大限に生かすことができます(｀・ω・´) 前提となる知識 DDDはオブジェクト指向デザインパターンの本ですので、オブジェクト指向設計における一定の経験と知識は必須となります（デザインパターンについての知識は必須ではありません）。 リレーショナルデータベースを備えたエンタープライズWebアプリケーションを前提としているので、サーバーアプリケーション設計・開発の経験があると理解がスムーズです。 アーキテクト向けの本ですので、UMLのクラス図や

こちらの本を読んででのレポートです。現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法【電子書籍】[ 増田亨 ] 価格：3175円 (2017/11/4時点) 複雑な業務ロジックは「適切な境界」で分離されていれば理解しやすくなる！ …が最近の自分の持論なのですが、じゃあ「適切な境界」って何よ？　…と言われると、うまく言語化説明できない。 そんな私にたくさんヒントを与えてくれた本でした。 なかなか消化しきれていないところもあるのですが、腹落ちさせるためにもブログに落としてみます。 このブログに書いたことをまとめると・・・ 修正が大変なのはロジックが分散しているから データとロジックをひとつのクラスにまとめるとロジックが分散しない！ じゃあWeb APIでサービス間連携するときも、データを持つほうにロジックを寄せるべき…　と思ったら、そうでもない？ この本のすごい

最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク

本題の前に まず「オブジェクト指向」という言葉を知っただけのまったくの初心者の方のために例を出してイメージをつかんでもらいます。あくまで例なので色々不完全なのはご了承ください。言語はJavaですがJavaを知らなくても何となく分かるように書きます。 オブジェクト指向とは （即物的に言えば） データとそれに関わるメソッドを クラス(class) にまとめてプログラミングすることです。 例えば友達の情報を管理するために以下のような「友人」クラスを考えてみましょう。 class Friend { String name;//名前 String phoneNumber;//電話番号 String mailAddress;//メールアドレス Friend(String name, String phoneNumber, String mailAddress) { //thisは自身を意味する thi

ちょうど弊社内の同僚と輪読会をしていた書籍の著者であるところの増田さんがやるハンズオンがあると聞いて行ってきた。 第一回はこちら。動画で見てもなかなかおもしろかった。 youtu.be アソビューについて www.asoview.com の運営会社。 椅子がキャンプ用のやつで、会社特有感出てて面白い。 テーマは「型」 型とは、オブジェクトにおいて有効な値および演算を定義するもの = ストラウストラップ先生の受け売り。 ユーザー定義型を作って、モデルと実装を一致させるハンズオン 前説自体は、よくあるオブジェクト指向の概念の説明。 コードの臭いとか、リファクタリングの話とか。 ネタは「購入の平均単価」。 このビューを表現するユーザー定義型を実装しよう。 以下は、やりながら感じたことの箇条書き。 自分がどんなロジックで生成されるかは、誰が知るべき？ 売上高 / 購入量 で導出される「平均単価」の

細々と書き直したので、最初の公開の時とちょっと変わっています。 最近ようやくこの手の「良い設計」をちゃんと解説してくれる書籍が出版されるようになってきて、良い時代になったなぁ。データベースであればドメインを定義したり、正規化といった、ある程度定型的な観点が有る手法が有るので割と以前から良い設計に対するアプローチが明確だった気がするけど、アプリケーションになるとなぜか、あまり見かけなかった。 今までコードを書いたことが無い人が読んでも、今一つ納得感が無いような気がするけど、一度でも他人のコードの改修に苦労したことが有れば、発見が有る本。 全編に渡って素晴らしい知見が多いのだけど、まずはChapter1の「小さくまとめてわかりやすくする」だけでもしっかり読んだ方がいい。特に値オブジェクト重要。 値オブジェクトを使ったリファクタリングと機能追加を体験するだけでも、ソフトウェアの複雑さのコントロー

kanjava.connpass.com 日時：2017/10/21(土) 13:30 〜 17:30 場所：エムオーテックス新大阪ビル 2F 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版この商品を含むブログ (2件) を見る 今回のテーマは「現場で役立つシステム設計の原則」の著者である増田さんをゲストに迎えてのDDD特集。関ジャバですがScalaの話が多くてJavaの話は少なめ。Scala Kansai Summitのトートバッグを頂きました。 以前投稿済みだが「現場で役立つシステム設計の原則」は読んだものの、「理想はそうだがうまくいくのか？」という懐疑的な思いも若干あったが、パネルディスカッションを聞いてみると結局のところ、理論も大事だがどれだけ本気

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版この商品を含むブログ (2件) を見る 「現場で役立つシステム設計の原則」をちびちび読んでたのを読み終えたので雑記。 一言感想 DDDといえばエヴァンス氏のドメイン駆動設計がありますが、そちらを読んでなくても十分理解できる内容でした。本書はガチなDDD本ではなく、現場目線からの変更に強いコードをどう設計して書くかという内容を具体例を交えて説明しています。個人的には３章「業務ロジックをわかりやすく整理する」４章「ドメインモデルの考え方で設計する」辺りはとてもわかりやすいし実践しやすい内容で、新人氏にはリーダブルコードと合わせてお勧めしたいなというところで良書でした。 願わくば本書に出てきたサンプルを実践した形の動

ざっくり説明すると、DDDの文脈にあるドメインモデルやドメインオブジェクトとかを意識してプログラミングとかやっていきましょうという感じ。 エリック・エヴァンスのDDD本は概念的な話やユビキタス言語とかをちゃんと定義してドメインモデルを作っていってチーム全員でやっていき！って感じで、 なんか手っ取り早くいい感じのアーキテクチャとかプログラミングでパワーアップして、いい感じのプロダクトを作りたい！！！！ って人には難しい内容となっていたと思います。 （DDD本、自分はとてもいい本だと思ってますので、あとで読むのはおすすめします） 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版この商品を含むブログ (2件) を見る 本書はDDD本と違って、プログラミングからのア

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版この商品を含むブログ (2件) を見る 毎朝15分の読書会で本書を読んだ。現場で役立つということでチームで共有するテーマとしても良い本だと思う。 コードをわかりやすくまとめるテクニック 小さくまとめてわかりやすくする 場合分けのロジックを整理する 業務ロジックをわかりやすく整理する 前半はコードをシンプルにわかりやすくする手法について。リーダブルコードのような形でわかりやすく良いコードに変えているテクニックの解説が中心。 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 作者: Dustin Boswell,Trevor Foucher,須藤功

増田亨氏の「現場で役立つシステム設計の原則]」批判の第２編です。 （２）ポリモーフィズムは何のために？オブジェクト指向の要件本書には「変更を楽で安全にするオブジェクト指向の実践技法」というサブタイトルが付与されています。オブジェクト指向が何かという点については、論者によって違いはあるものの、以下の３つが要件とされることには、多くの人が合意するでしょう。 カプセル化インヘリタンス（継承）ポリモーフィズム（多態）前回で明らかになったように、カプセル化は、オブジェクト指向とは独立にモジュール分割の指導原理としてデイビッド・パーナスにより提唱された「情報隠蔽」を敷衍したものです。オブジェクト指向の要件ではありますが、オブジェクト指向固有のアイデアではありません。 インヘリタンスは便利な機能ですが、コンポジションや移譲により代替できるので、オブジェクト指向の本質的な要件とは見做されなくなってきたかと

DDD Alliance!主催の「現場で役立つシステム設計の原則 Night!」での書評LTスライドです。

増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本

『現場で役立つシステム設計の原則』という本を付箋を付けながら一通り読んだ?ので 個人的に面白かったところを自分用にメモしておきます。 本当にメモです。 本質とはだいぶ違うところだと思うので買って読んで下さい。。 (付箋はつけていたけどうまく説明できなさそうなところは消しました。) 目的ごとに変数を用意する 段落わけと、目的ごとの変数で分かりやすい。 一度作った変数を変更するのを破壊的代入といい、それをなくすことでコードが安定するそうです。 int basePrice = quantity * unitPrice int shippingCost = 0 if (basePrice < 3000) { shippingCost = 500 } int itemPrice = ... コレクション型を扱うロジックを専用クラスに閉じ込める これをコレクションオブジェクトやファーストクラスコレクシ

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...