GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリですYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
アクターモデルとアプリケーションアーキテクチャの関係 - nkty blog
背景 マイクロサービスアーキテクチャが浸透し、それに伴いDDDを導入する企業も増えている気がします。 それと同時に、アクターモデルの話題も最近以前より聞くようになった気がします。 ただ、以下のような疑問を持つ人は多くいるのではないでしょうか？ アクターモデルは聞いたことがあるけど、重要性が分からない 使い所が分からない サーバーレスコンピューティングなの？でもAkkaの説明ばかり出てくるけど？ こういう状況になっている要因の一つは、おそらく、アクターモデルの説明の多くが分散システムにフォーカスしており(当たり前なんですが)、アプリケーションアーキテクチャとの関係性については、使う人まかせになっているためではないでしょうか。 ここでは、アプリケーションアーキテクチャと合わせて、アクターモデルの使い所を考えてみます。 先に結論 アクターモデルは、分散環境で実行するアプリケーションを開発するため
Firebaseの存在をフロントエンドから隠蔽するために
「Firebase は安いし楽だしマジ最高」という一心で技術選定してしまったプロダクトが成功して見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そして （特性やスキルセット的に）RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まるも、Firebase べっとりなアプリケーションすぎて移行しづらいといった問題に出会うかもしれません。 そのような場合に備え、Firebase の存在を隠蔽して開発することに挑戦してみましょう。 注意: Firebase を剥がしているときに「俺、次は絶対そうするわ」と感じたものを書いているだけであり、まだ実際にはこのパターンでプロダクション導入していません。 あくまで個人開発で試してみていけそうと思ったので、提案しますという体です。 また Firebase
CQSとCQRSの違いはメソッドの分離かモデルの分離かという観点 - Qiita
この記事について 先日 DDD-Community-Jp の DDD Talk MeetUp #2 というイベントでトーク枠にて参加させて頂き Flyweight DDD というアーキテクチャスタイルの提案とする一つのスライドを発表させて頂きました。 https://speakerdeck.com/hirodragon112/ddddao-ru-nita-miqie-renaifang-hezeng-ru-2ceng-plus-cqs-akitekutiya-flyweight-ddd ただ、本稿はこのスライドの「内容」とは全く関係ありません。 本稿で取り上げたいのはこのタイトルに登場している CQSという単語についてです。 このスライドをきっかけにCQSとCQRSの違いについて自分なりに思考の整理を記載したいと思います。 CQS ? CQRS ? きっかけは twitter にて @j5
複雑な条件と戦う
複雑な条件の組み合わせで - テストが難しく - 実装が肥大化し - 変更が辛い 状態になったコードを改善する。 Specification Pattern/仕様パターン について、「実装的に嬉しいこと」にフォーカスして整理。
Developers.IO 2018 で「API 設計」の話をしてきた #cmdevio2018 | DevelopersIO
緊張すると声がアムロ・レイになる都元です。 ここからしばらく、キャッチコピーの迷走期が始まりますのでよろしくお付き合いください。 さて、去る 10/5 (金) 秋葉原 UDX にて開催された Developers.IO 2018、その中で 「クラスメソッドにおける Web API エンジニアリリングの基本的な考え方と標準定義」 という仰々しいタイトルで1講座持たせていただきました。 スライド 話したかったことと、話したこと 本セッションで話したかったことはだいぶ多岐にわたり、当然 40 分では話しきれないので、当初は次の 2 テーマに絞ってお話しようと考えてスライドを作っていました。 アプリケーション動作ログガイドライン RESTful / リソース指向 API 設計 しかし実際にスライドを作ってみると、それぞれで 40 分の規模となってしまい…。 ログの話は断腸の思いで見送りとさせていた
Service Objectがアンチパターンである理由とよりよい代替手段（翻訳）｜TechRacho by BPS株式会社
近年、RailsアプリにService Objectを追加するメリットを説く記事が次から次へと量産されています。私は本記事において、それがなぜ正しくないかを述べたいと思う次第であります。もっとよい方法はあるのです。 私はこれまで、Service Objectに関するネット上の議論にときおり参加しては、問題に対するまっとうな解決方法としてService Objectが正しくない理由について繰り返し見解を述べてきました。実際、私は多くの場合においてService Objectよりもっとよい解決方法があると考えるのみならず、Service Objectはオブジェクト指向設計原則への配慮が損なわれている兆候を示すアンチパターンとして取り扱っています。 このような深遠なポイントを細切れのツイートやコメント欄を追って理解するのは大変です。そこで私は、私の見解を正確に表すいくつかの現実的なコードを詳しく
DHHはどのようにRailsのコントローラを書くのか | POSTD
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
ドメイン駆動設計 ～ユーザー、モデル、エンジニアの新たな関係～
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
言語機能としての型、概念としての型 - プログラマーの脳みそ
某エントリが型について再考するきっかけになったのは事実だが、個々人の思想の成否を問う気がないのでとくにリンクはしない。ここでは型とは何かという点について僕なりの思想を記しておきたい。 データ型を区別しない世界 ごくシンプルなチューリングマシンを考えよう。 チューリングの仮想機械は、 無限に長いテープ その中に格納された情報を読み書きするヘッド 機械の内部状態を記憶するメモリ で構成され、内部状態とヘッドから読み出した情報の組み合わせに応じて、次の動作を実行する。 ヘッド位置のテープに情報を書き込む 機械の内部状態を変える ヘッドを右か左に一つ移動する 上の動作を、機械は内部状態が停止状態になるまで反復して実行し続ける。 チューリングマシン この原始的な世界において「型」はない。メモリは抽象的で全てのメモリは同等に扱われ区別する必要はない。 また、チューリングマシンに程近い原始的なプログラム
ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？
スクウェア・エニックスの人気RPG「ドラゴンクエスト」シリーズの最新作「ドラゴンクエストX（ドラクエ10）」はシリーズ初のオンライン作品となりましたが、その舞台裏は一体どうなっていたのか。ゲームの世界観を支えるサーバシステムがどのように構成されているのかということや、ドラゴンクエストⅩならではの仕組みや機能から開発の苦労話まで、株式会社スクウェア・エニックス開発部プログラマ森山朋輝さんが語っています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/NW/C12_P0040.html 森山朋輝： 皆様、本日はお集まり頂きどうもありがとうございます。このセッションを担当させて頂きます、株式会社スクウェア・エニックス開発部所属の森山朋輝と
フェイルセーフ と フールプルーフ
情報処理技術者試験対策メモ フェイルセーフは機械が障害を発生させても安全に動作すること フールプルーフは人間がミスをしても安全に動作すること。あるいはミスをしないように設計すること 今まで解説文を個別に読んでもどう違うのかなかなか頭に入らなかったのだが、主語が機械か人間かの違いが区別の大元だった。
抽象のハシゴ － 牝牛ベッシー － ８ 富 富と言う言葉はきわめて高いレベルの抽象で、ベッシーのほとんどの特性レベルへの言及は省略さ れている。 ７ 資産 ベッシーを「資産」と言う時��
抽象のハシゴ － 牝牛ベッシー － ８ 富 富と言う言葉はきわめて高いレベルの抽象で、ベッシーのほとんどの特性レベルへの言及は省略さ れている。 ７ 資産 ベッシーを「資産」と言う時、なお多くの彼女の特性が落ちている。 ６ 農場資産 ベッシーが「農場資産」に含まれる時は、ただ彼女が他の全ての農場の売れる物件と共通の点だけ が言及されている。 ５ 家畜 ベッシーが「家畜」と呼ばれる場合には、彼女が豚・鶏などと共有している特性だけが言及されて いる。 ４ 牝牛 「牝牛」の語は、われわれが牝牛 1、牝牛 2、牝牛 3…牝牛ｎに共通の特性を抽象化したものを代表 する。特定の牝牛の特有の特性は捨てられる。 ３ ベッシー 「ベッシー」(牝牛 1)の語は、２のレベルの知覚の対象にわれわれが与えた名である。 名は対象そのものではない。それはただ対象を代表し、対象の諸特性の多くへの言及を省く。 ２ 知覚の
高凝集性と低結合性 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設計だけでコードを書けないなら断る、TDD伝道師の原点
集約の設計と実装
ScalaでウェブAPIを書いている人が設計や実装やその他について話そうか
モデルとはなんなのかって話 - polidog lab++
はてなブログ | 無料ブログを作成しよう
