オブジェクト指向プログラミングが学べる書籍たち もし私が今から最初から学ぶならこの順番でこの本読むだろうという紹介です。 新人プログラマの方々は右も左も分からないというところからスタートとなるため、オブジェクト指向プログラミングを学ぶときに何から学べば良いか全くわからないという状況かと思います。 オブジェクト指向プログラミングを学んでいると自然と出会うドメイン駆動設計についても同様です。 そうした方々が書籍から学ぼうとした場合に、少しでも効率良く進められる順番を示してあげられれば良いなと思って紹介します。ただし、各書籍についての詳細な説明は書いていません（というか結構忘れててかけない）…。 なお、前提言語はJavaで言語構文にも十分詳しいことが大前提です。 以降、オブジェクト指向プログラミングはOOPと略します。 現場で役立つシステム設計の原則 OOPらしさの雰囲気がわかります 入り口に最

こんにちは。west-cです。 携わっている新規サービスにてドメイン駆動設計（以下、DDD）を取り入れた開発を行っていることから、去年の秋頃からDDDの学習をはじめました。 今回は、私が学習にあたり読んだおすすめ書籍を紹介します。 目次 目次 ドメイン駆動設計とは おすすめ書籍 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 ドメイン駆動設計 モデリング/実装ガイド ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 実践ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 おわりに ドメイン駆動設計とは 本題へ入る前に、「そもそもDDDって何？」という方へ3行でとてもざっくりと説明します。 DDDとは、ソフトウェアで問題解決しようとする領域（ドメ

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！　Yahoo!ショッピングクーポンチームの小倉です。 前回のフロントエンド技術刷新の話とは打って変わり、今回は2019年に行ったバックエンド技術刷新の話です。 刷新前のシステムはノンフレームワークPHPのモノリスでしたが、現在は主にJava/Spring Bootでマイクロサービス化しています。今回は、その中でもっとも仕様が複雑だったマイクロサービスにおいて、ドメイン駆動設計(Domain Driven Design:DDD)を実践した話をご紹介します。 ショッピングクーポンの自由度を知る みなさんは、ショッピングの商品が割引になるクーポンをご存じでしょうか？　実は、クーポンには、ヤフーが予算をだして発行する「モールク

技術広報のsyoneshinです。 今回は当社の開発組織メンバー達に 読んでよかった 自身が影響を受けた 他者にも読んでほしいと思った という観点で 『おすすめの技術書』とおすすめポイントを聞きました。 質問：皆さんの「おススメの技術書」 を教えてください。 【目次】 おすすめの技術書ランキング 『リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』 『マスタリングTCP/IP 入門編』 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』 『達人プログラマー 職人から名匠への道』 『Webを支える技術』 『SQLアンチパターン』 『Java言語で学ぶデザインパターン入門』 『はじめて学ぶ　ソフトウェアのテスト技法』 『UNIXという考え方―その設計思想と哲学』 『Effective Jav

はじめに 先日、増田亨さんの「現場で役立つシステム設計の原則」を読んだので感想を。 しばらく前に買っていたのですが、年末で余裕があったのでやっと読了しました。 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行本（ソフトカバー） 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版 現場で役立つシステム設計の原則 概要 全10章で構成されていて、総じてDDDやオブジェクト指向メインの話になっています。 なぜそうするのかという理由とサンプルコードと一緒に説明がなされていて、イメージがわきやすくなっています。 感想 1番の感想は、「新卒1年目で読

This article is a Private article. Only a writer and users who know the URL can access it. Please change open range to public in publish setting if you want to share this article with other users. ※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎ

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

読んで明らかに仕事プログラミング力が上がった本ってそれなりにあって、 「リーダブルコード」 「現場で役立つシステム設計の原則」 「増補改訂版Java言語で学ぶデザインパターン入門」 「新装版 リファクタリング―既存のコードを安全に改善する」 はめちゃくちゃいいんでオススメですね

概要 developers.cyberagent.co.jp こちらで 課金システムをマイクロサービス化した サービス自体の設計をDDDにした という対応をしました。 当時は試行錯誤の連続でしたが対応から１年程経ち、ある程度設計もfixされてきたので知見をまとめます。 知見 前提 Clean Architectureの図は多くの人が目にしているように以下の通りです。 今回話す内容は青色の部分を除いた ドメイン層：黄色の部分 ユースケース層：赤色の部分 インタフェース層：緑色の部分 です。 ディレクトリ構成 goのリポジトリの構成は以下のようにしています。 . ├── Dockerfile ├── Makefile ├── README.md ├── cmd/ ├── codes/ ├── config/ ├── docker-compose.yml ├── domain/ ├── go.m

こんばんは、kuwana-kbです。 今回はソフトウェア設計に関する書評です。 最近、チームの開発タスクで「○○機能を実装する」というタスクをこなせるようになってきました。 どんなタスクか具体化すると、仕様書にある「入力」と「出力」に基づいた実装を書くことです。 これができるようになってきたのは、大変喜ばしいことです。これができるということは、自分の手でプログラムを作って動かせるということを意味します。 例えば、Lambdaなどで日常のタスクを自動化したりなんかもできますね。 しかし、喜ばしいのと同時に新たな課題を感じています。 それは設計です。どうしたら変更に強くて可読性の高いソースコードになるのか、といった課題を感じています。 「作れるようになったのはいいけど、この作り方でどれくらい運用できるだろうか…他の人からみたら読みづらくないだろうか…」という不安に駆られる感じですね…。 そこで

はじめに 未経験新卒でエンジニアを始めてから一年以上がたち後輩が入ってきました。 よくおすすめの書籍を聞かれるので、この機会に自分が読んだおすすめの本をまとめてみました。 読んだ本を数えてみたら38冊も読んでいて正直自分でもびっくりです。 今回はその中から厳選した9冊を紹介します。 ※ここではJavaなどに絞らず、サーバサイドエンジニアとしておすすめの書籍を紹介します。 私の未経験当時のスペックと現状 未経験当時 大学1年生の時にC言語を授業で習ったがやる気もなくループ処理なども分からず 就活でエンジニアに決まってからPaizaの問題を解きまくりA問題も多少解けるレベル （ただし変数名はaaaaとかhogeeeを多用w） 現状 書籍を大量に読んでアウトプットしていたおかげで（もちろんまだまだ勉強中ですが） ダメなコード、良いコードの判別が出来て、実装にも落とせる。 アーキテクチャを採用した

この記事を書いたあたりから、よりDDDについて知りたくなって追加で読み始めた本 takanamito.hateblo.jp 現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 業務におけるプログラミングでオブジェクト指向を実践するにはどうすればよいかを、ここまで具体的に書いてくれてる本は初めてだったので読んでよかった。 1章からいきなりドメインオブジェクトの軽い説明と例示 3章ではドメインロジックをドメインオブジェクトに抽出していく説明 4章ではさらにその手前の、業務フローからドメインオブジェクトを見つけていく手法と、ドメインオブジェクトの育て方 少し飛んで8章ではドメインオブジェクトとAPIレスポンスをどう対応さ

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 目次流しは以前書きましたが、読み終わってるので改めて。 一緒に開発する人には読んでおいてほしい。可能なら手元に置きながら開発してほしい本です。手頃なサイズ、重量、厚さ、価格ですし。鈍器本系に比べれば持ち運びやすい。実際レビューやペアプロの際、「あの本に書いてるんだけど・・・」という感じで何度か参照しています。 読書会をしてみて 4つのイベントに参加しました。うち2つは輪読形式の読書会で、最初から最後まで読み上げです。有用なのと同時に危険でもある、というのが読書会での感想です。 平易な文章で理解しやすいように思えるのですが、表面だけで理解した気になっていると間違いな

現場で役立つシステム設計と実装、リファクタリングに開発プロセスにOOPとDDDの本 ドメイン駆動設計（DDD: Domain Driven Design）の実践者としても知られる増田 亨さんの2017年7月の本。ネットでもかなり話題になったので読んだ人も多いのではないでしょうか。 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨発売日: 2017/07/05メディア: Kindle版 タイトルは「～システム設計～」となっていますが実際は設計以外の話もあるので、もう現場で役立つシステム「開発」全般で役立つ原則本となっています。 技術評論社から各種出ている一般的な技術書サイズで422とボリュームはありますが、内容はかなり推敲されていて文章はとても読み易いです。 サンプルコードはすべてJava。しかし本書で述べられているテクニックはかの『リファクタ

IntelliJ IDEA, PlantUML, Spock を使って DDD, UDD(仮) を試みている話IntelliJPlantUMLDDD 10月頃から、一部有志を集めて学習会を開いていて、その第一弾に選んだ題材が DDD (Domain-driven design) だった。 まだ道半ばであるが、ここいらで一度まとめておきたい。 tl;dr Kotlin, IntelliJ, PlantUML, Spock の使い方の解説はない DDD の解説はない 正しい DDD とは、とかも無いです UDD は、ubiquitous language driven design 造語です DDD を目指しドメイン設計を実施してみて、何が変わったのか 実施前 業務ドメインが分からなすぎた でも、取り敢えず設計・作成するだけならこれでも行けた でも、やっぱり業務知らないと、将来的に辛い お客さ

フューチャーアーキテクト Advent Calendar 2017の2日目です。 はじめに システム設計が大好きで大嫌いな皆さん、こんにちは。 突然ですが、皆さんはどのようにシステム設計における ドキュメント腐る問題 に立ち向かっていますか？ ドキュメント腐る問題とは、設計時に作成した各種ドキュメントがGoogle Driveやファイルサーバ上で陳腐化してしまい、現状の正しい状態を指していないことです。せっかく新規参画者がキャッチアップしようとしてもドキュメントが真実を示していないという怖いやつですよね。 解決策としては、各種ドキュメントを、MarkdownやAsciiDoc、UMLはPlantUMLやmermaid、ERDはPlantUMLやerd、画面遷移図はUI Flow、REST-API設計はSwaggerなど、なるべくテキストベースで管理し、GitHubなどのリポジトリで管理する

この記事はCrowdWorks Advent Calendar 2017の4日目の記事です。 はじめに 今年CrowdWorksにエンジニアとして新卒入社した@kinakoboです。CrowdWorksでは10月から新たな試みとしてドメイン駆動設計（DDD）を実践しています。 DDDを実践するに至った経緯は、サービスの規模拡大に伴いアプリが肥大化し、技術的負債が増えてきたことで、機能追加をスピーディーに進めづらくなってきたからです。 今回実装しようとしている機能を今まで通りRuby on Railsを利用して実装することは可能ですが、変更に強い柔軟なサービスにするためにもDDD+Scalaで実装し始めています。 DDD未経験の状態から2ヶ月実践してみて、まだ道半ばですが感じたことを書きます。同じような課題感を持っている方の参考になれば幸いです。 エヴァンス本に挫折したら･･･ DDDと言え

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

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