現場で役立つシステム設計の原則

554ブックマーク「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書 - ビープラウド社長のブログ

shacho.beproud.jp

355ブックマーク現場で役立つシステム設計の原則で個人的に面白かったところメモ - Qiita

290ブックマーク現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる - Qiita

248ブックマーク「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～

phpmentors.jp

240ブックマーク『現場で役立つシステム設計の原則』を読みました - 人間のあるべき姿の探索

godiva-frappuccino.hatenablog.com

105ブックマーク「現場で役立つシステム設計の原則」の目次流し - 日々常々

irof.hateblo.jp

91ブックマークドメインモデルとは(「現場で役立つシステム設計の原則」より) - Qiita

87ブックマーク現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法

gihyo.jp

関連ブログ

やわらかテック•2年前

【書評】現場で役立つシステム設計の原則はオブジェクト指向の入門によさげな本だった

Amazonを徘徊していたところ、面白そうな本を見つけました。現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法作者:増田亨技術評論社Amazon 目次を見ると、オブジェクト指向の考えとドメイン駆動設計(DDD)を組み合わせて、変更に柔軟に耐えうるコード設計をどのように実現するかを教えてくれる本のようです。社内の輪読会でドメイン駆動設計(DDD)を扱ったのですが、どのようにコードで表現するかがイマイチよく分からなかったので、買って読んでみることにしました(いつもの衝動買い...😂)。こちらの書籍の購入を検討している方、どのような方にオススメできるのかを書評と…

#エンジニア#書評#現場で役立つシステム設計の原則

「現場で役立つシステム設計の原則」読書会 vol.10

第10回の感想です。前回の感想はこちら。 patorash.hatenablog.com 会社のブログのレポートはこちら。 tech.rhizome-e.com 最後なのでみんな参加できるようにしようということで日程調整してから行ったので少しずれ込みました。というても5月前半だったので、私がブログ書くのが遅かっただけですね、はい。色々バタバタしてまして。もう次の読書会が始まってますし（汗） 10章オブジェクト指向設計の学び方と教え方オブジェクト指向の説明は意味不明というところ…。まぁそこまで意味不明とは思っていなかったんだけれど、ドメインオブジェクトを設計していくという考え方にはあまりなっ…

「現場で役立つシステム設計の原則」読書会レポート vol.10

株式会社リゾームシステム企画・開発部第4グループの平松です。今回は、読書会の第10回目のレポートになります。前回のレポートは、こちらになります。 tech.rhizome-e.com 10回目レポート今回は、第10章「オブジェクト指向設計の学び方と教え方」で参加者は6名でした。それぞれの感想・意見交換ドメインオブジェクトを設計していくという考え方にはあまりなってなかった受託開発をしているときはリファクタリングをする機会があまり与えられないため、良さがよくわかってなかったオブジェクト指向は言葉で説明するのは難しいオブジェクト指向を学ぶにはリファクタリングがいいと思う手を動か…

「現場で役立つシステム設計の原則」読書会 vol.9

読書会自体はGW前にやっていたのですが、諸々あって書くのが遅くなってしまった…。第9回の感想です。前回の感想はこちら。 patorash.hatenablog.com 会社のブログのレポートはこちら。 tech.rhizome-e.com 9章オブジェクト指向開発のプロセス開発の基本はV字モデルではあるが、そのサイクルが異なる。今はアジャイルで開発することが主流なので、同じチームで全部を担当することが普通になっている。大体うちでもそういうプロセスでやってる。しかし、ここに書いてある通り、分析・設計にほとんど時間をかけずにとにかくプログラミングするという流れはある。特に、Railsでは顕…

「現場で役立つシステム設計の原則」読書会レポート vol.9

株式会社リゾームシステム企画・開発部第3グループの渡辺です。今回は、読書会の第9回目のレポートになります。前回のレポートは、こちらです。 tech.rhizome-e.com 9回目レポート今回は、第9章「オブジェクト指向の開発プロセス」を読み進めました。それぞれの感想・意見交換開発の進め方分析・設計にほとんど時間をかけずにとにかくプログラミングするという流れはある。特に、Railsでは顕著ではないかと思う。ちょっと規模が大きくなるとコードの見通しが急速に悪化するというのは、身に覚えがある。コードの見通しが悪い手がつけられないほど難解もう少し分析や設計に時間をかけるのが…

「現場で役立つシステム設計の原則」読書会 vol.8

第8回の感想です。前回の感想はこちら。 patorash.hatenablog.com 会社のブログのレポートはこちら。 tech.rhizome-e.com 8章アプリケーション間の連携 1つのサイトであっても、様々なシステムが連携しあっている。アプリケーション間の連携方式。ファイル転送データベース共有 WebAPI メッセージングうちでよくやる方式なのはファイル転送だろう…。オンプレの環境との連携とかがあるので仕方ない面はある。WebAPI連携は多少やっている。自分の担当製品とその派生製品で、API連携している。WebAPIはGraphQLで作っていっているが、ちょっとわかりにく…

「現場で役立つシステム設計の原則」読書会 vol.7

第7回の感想です。前回の感想はこちら。 patorash.hatenablog.com 会社のブログのレポートはこちら。 tech.rhizome-e.com なお、この回の会社のブログのレポートの担当が私だったので、書きたいことはそちらにほぼ書いちゃってる…。 7章画面とドメインオブジェクトの設計を連動させる画面にロジックを埋め込むと複雑化してくるのはすごくわかる…。表示のためのロジックと業務ロジックを分ける意味では、ビューヘルパーを使ったり、デコレーターを噛ましておくといいとは思う。Railsの場合はビューヘルパーはグローバルメソッドのようになってしまうので、あまり好みではないけれど…

「現場で役立つシステム設計の原則」読書会レポート vol.8

株式会社リゾームシステム企画・開発部第3グループの鳥井です。読書会の第8回目のレポートです。前回のレポートは、こちらになります。 tech.rhizome-e.com 8回目レポート今回は、第8章「アプリケーション間の連携」で参加者は4名でした。それぞれの感想・意見交換アプリケーション間の連携方式代表的なものは以下の4つファイル転送データベース共有 Web API メッセージング弊社でよくやる方式なのはファイル転送、WebAPI連携も多少やっている。 Web API設計更新も削除もPOSTにするアプリケーションの独立性が高くなり、修正の影響を小さくできる更新や削除も…

「現場で役立つシステム設計の原則」読書会レポート vol.7

株式会社リゾームシステム企画・開発部第4グループの尾古（@patorash）です。読書会の第7回目のレポートです。前回のレポートはこちらです。 tech.rhizome-e.com 7回目レポートそれぞれの感想画面にロジックを書いてしまうこと画面に表示するロジックと業務ロジックが混在してしまう 1章で言われていた、ちょっとした条件分岐を追加したら複雑になってしまう件が頻発するビューにif文が入ると見辛くなる特に、slim*1で書いていると、閉じタグがないため、インデントが重要になるが、if文が入るとかなり見辛い複数画面にコードが重複してしまう表示のロジックと業務ロジックを…