5.3 Actor creation plus addresses in messages means variable topology
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』(以降DDD)は、「
出版-購読型モデル(しゅっぱん-こうどくがたモデル、英: Publish/subscribe)は、非同期メッセージングパラダイムの一種である。メッセージの送信者(出版側)が、特定の受信者(購読側)に直接メッセージを発行するプログラムではなく、発行(出版)されたメッセージはクラス分けされ、どんな受信者が居るのかは知らない。受信者は興味のあるクラスを指定しておき、そのクラスに届くメッセージだけを受け取り、どんな送信者が居るのかは知らない。送信者と受信者の結合度が低いため、スケーラビリティがよく、動的なネットワーク構成に対応可能である。 出版-購読型モデルはメッセージキューパラダイムと対比され、一般に大きなメッセージ指向ミドルウェアの一部として使われる。一部のメッセージシステム(Java Message Serviceなど)は、出版-購読型とメッセージキューの両モデルをサポートしている。 出版-
ケント・ベック ケント・ベック (Kent Beck) はエクストリーム・プログラミング (XP) の考案者でアジャイルマニフェスト (Agile Manifesto) の起草者の一人。彼はデザインパターン、テスト駆動開発、Smalltalkに関する本を書いた。ベックはウォード・カニンガムと一緒にCRCカードを普及させた。SmalltalkのユニットテストのフレームワークであるSUnitを開発した。さらにエーリヒ・ガンマと共同でJavaのユニットテストのフレームワークJUnitを開発した。ケント・ベックはオレゴン大学のコンピュータサイエンスの修士号を取得している。 Smalltalk Best Practice Patterns. Prentice Hall, 1996. ISBN 0-13-476904-X. 『ケント・ベックのSmalltalkベストプラクティス・パターン — シンプル
モバイルアプリのUIパターンを手軽に参照できるリファレンスの第2版。デザイントレンドの変化に対応して全面改訂。主要なプラットフォームで動くモバイルアプリの画面例を1,000点以上使いながら、ユーザーインタフェースの定番パターンをグラフィカルに解説します。本書で紹介する83個の基本パターンと7個のアンチパターンが、使いやすいモバイルアプリをデザインするうえでクリアしなければならない設計上の課題を解決してくれます。 掲載UIパターン:ナビゲーション、フォーム、テーブル、検索、並べ替え、フィルター、ツール、グラフ、誘導、ソーシャル、フィードバック、アフォーダンス、ヘルプ、アンチパターン 監訳者まえがき 序文 まえがき 第1章 ナビゲーション 1.1 主要なナビゲーションのパターン(永続的) 1.1.1 Springboard(スプリングボード) 1.1.2 Cards(カード) 1.1.3 Li
コンピュータプログラミングの用語で制御の反転(Inversion of Control、IoC)とは、なんらかの種類のプログラムにおいて、プロシージャを「呼び出す側」と「呼び出される側」が、従来のプログラムとは逆になるようにする、ということである。 たとえば従来の、シェルのコマンドで実行される古典的なアプリケーションではメインループが最上位で動いており、そこからライブラリなどのAPIを呼ぶのに対し、ウェブブラウザ中で実行されるJavaScriptアプリケーションでは、各種のハンドラがブラウザから呼ばれてアプリケーションが動く、というのも大きく見ればそのような「反転」の一種と言える。これが使われる一例としては、プログラムのモジュール化を促進して、その拡張性を高めるために用いられている[1]。 用語として Inversion of Control を略した IoC を広めたのはロバート・マーテ
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "依存性の注入" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2021年6月) 依存性の注入(いぞんせいのちゅうにゅう、英: Dependency injection)とは、あるオブジェクトや関数が、依存する他のオブジェクトや関数を受け取るデザインパターンである。英語の頭文字からDIと略される。DIは制御の反転の一種で、オブジェクトの作成と利用について関心の分離を行い、疎結合なプログラムを実現することを目的としている。 dependencyを「依存性」と訳すのは本来の意味[1] から外れているため「依存オブジェクト注入」の用語を採用す
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "データフロープログラミング" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2025年3月) データフロープログラミング(英: dataflow programming)は、データフローの原理とアーキテクチャに準拠したプログラミングパラダイムであり、プログラムをオペレーション間のデータフローの有向グラフとして模型化する。データフロー言語は、関数型言語の特徴を共有しており、より数値処理に適したものになっている。 データフロー言語は、命令型プログラミングモデルなどの他の主要のプログラミング言語とは対照的である。命令型プログラミングではプロ
Decorator パターンの方針は、既存のオブジェクトを新しい Decorator オブジェクトでラップすることである。 その方法として、Decorator のコンストラクタの引数でラップ対象の Component オブジェクトを読み込み、コンストラクタの内部でそのオブジェクトをメンバに設定することが一般的である。 Decorator パターンは、既存のクラスを拡張する際にクラスの継承の代替手段として用いられる。継承がコンパイル時に機能を拡張するのに対し、Decorator パターンはプログラムの実行時に機能追加をする点が異なる。 /** 価格をあらわすインタフェース */ interface Price{ int getValue(); } /** 原価を表すクラス */ class PrimePrice implements Price{ private int value; Pri
テストダブル (Test Double) とは、ソフトウェアテストにおいて、テスト対象が依存しているコンポーネントを置き換える代用品のこと。ダブルは代役、影武者を意味する。 テストを実行するには、被試験システムに加えて、テスト対象が依存するコンポーネント (DOC; Depend-On Component) が必要になる。しかし、依存コンポーネントは、常に利用できるとは限らない。依存コンポーネントがテスト環境で利用できない理由には、次のようなものが挙げられる[1]。 入手できない。 テストで使いたい結果を返さない。 実行に時間がかかるなどの、望ましくない副作用がある。 こういった問題を回避するには、依存コンポーネントを、テスト用のコンポーネントと入れ替えるテクニックが利用できる。この代用のコンポーネントを、テストダブルと呼ぶ。 ジェラルド・メサローシュは、テストダブルのパターンとして、次の
ソフトウェア開発におけるアンチパターン (英: anti-pattern) とは、必ず否定的な結果に導く、しかも一般的に良く見られる開発方式を記述する文献形式を言う[1]。その内容は、基本的には、否定的な開発方式の一般的な形、主原因、症状、重症化した時の結果、そしてその対策の記述からなる[2]。 デザインパターンを補完・拡張する関係にあるもので、多くの開発者が繰り返すソフトウェア開発の錯誤を明確に定義することにより、開発や導入を阻害する一般的で再発性の高い障害要因の検知と克服を支援することが目的である[3][4]。 ある問題に対する、不適切な解決策を分類したものをアンチパターンと言う[5][6]。 アンチパターンという呼び方は、アンドリュー・ケーニッヒ(英語版)が1995年に作り出したもので[7]、後に書籍The patterns handbook[8]で再掲された。 ギャング・オブ・フォ
契約による設計 契約プログラミング(けいやくプログラミング、英: Contract programming)または契約による設計(けいやくによるせっけい、英: Design by Contract; DbC)は、ソフトウェアの正確性[注 1]と頑健性[注 2]を高めるためのソフトウェア設計の方法論である。DbC はロバート・フロイド、アントニー・ホーア、エドガー・ダイクストラらの形式的検証の仕事を基礎にしている[1]。DbC は(抽象データ型に基づく)オブジェクト指向プログラミングにおける表明の利用や、継承に伴う表明の再定義の原理的規則、例外処理の原理的規則などを提供する[2]。 DbC は、バートランド・メイヤーによって提案された[3][4][5]。 「契約による設計」(DbC)における中心的な概念は、クライアントとサプライヤ[6]の契約 (contract) である。DbC における契
コンストラクタ(英: constructor)は、オブジェクト指向のプログラミング言語で新たなオブジェクトを生成する際に呼び出されて内容の初期化などを行なう関数あるいはメソッドのことである。対義語はデストラクタ。 オブジェクトの生成は、 メモリ割当(英: allocation) 初期化(英: initialization) の二段階を経て行なわれるが、コンストラクタを持つプログラミング言語ではメモリ割り当ては言語機能に組み込まれ、初期化用のコードのみを記述するのが普通である。 JISでは、「構築子」という直訳が割り当てられている規格もあるが[注釈 1]、「コンストラクタ」という用語が使われている規格もある[注釈 2]。 長音符を付けた「コンストラクター」という表記を採用しているドキュメントもある[4][5]。 C++、Java、C#、PHPなど、クラスベースのオブジェクト指向言語では、コン
Singleton パターン(シングルトン・パターン)とは、オブジェクト指向のコンピュータプログラムにおける、デザインパターンの1つである。GoF (Gang of Four; 4人のギャングたち) によって定義された。Singleton パターンとは、そのクラスのインスタンスが1つしか生成されないことを保証するデザインパターンのことである。ロケールやルック・アンド・フィールなど、絶対にアプリケーション全体で統一しなければならない仕組みの実装に使用される[1]。 Singleton パターンの一般的なクラス図を示す。 Singleton は同じ型のインスタンスを private なクラス変数として持つ。この変数には Singleton.getInstance() からアクセスする。Singleton のコンストラクタは private である。 このクラス図で注目すべきことは以下の3点であ
We are a global technology consultancy that delivers extraordinary impact by blending design, engineering and AI expertise. Our commitment to design-led thinking, engineering excellence and innovation means we prioritize people, build teams with strong technical foundations and embed AI into every step of the process – not just as a tool, but as a mindset. It’s this approach that sets us apart, sp
Software development is a young profession, and we are still learning the techniques and building the tools to do it effectively. I've been involved in this activity for over three decades and in the last two I've been writing on this website about patterns and practices that make it easier to build useful software. The site began as a place to put my own writing, but I also use it to publish arti
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。(参考文献の一覧は記事の最後にあります) 内容的には文献[2,3]を踏
「アクティブレコード、アクティブ・レコード」はこの項目へ転送されています。イギリスのレコードレーベルについては「ミュージック・フォー・ネイションズ」をご覧ください。 Active Recordはデータベースからデータを読み出すためのアプローチである。データベーステーブルあるいはビューの1行が1つのクラスにラップされ、オブジェクトのインスタンスがそのデータベースの1つの行に結合される。このクラスはデータベースアクセスのカプセル化も行う[1]。オブジェクトの生成後は、保存メソッドで新しい行がデータベースに追加される。 オブジェクトが更新されると、データベースの対応する行もまた更新される。ラッパークラスはテーブルあるいはビューの各カラムに対するアクセサメソッドを実装するが、それ以外の振る舞い(MVCのモデルが担当すべきロジック)も記述することができる[1]。 テーブルとクラスが一対一で結びつくこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く