サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
bliki-ja.github.io
http://martinfowler.com/bliki/ApplicationBoundary.html アプリケーションの境界をどのように定義するのか? ソフトウェア開発における未決着の問題のひとつに、ソフトウェアの境界をどのように決定するのかということがあります(ブラウザはオペレーティングシステムの一部でしょうか、それとも違うのでしょうか?)。 サービス指向アーキテクチャの提唱者の多くは、現在のアプリケーション開発はいずれなくなり、未来のソフトウェア開発は「複数のサービスを組み立てるもの」になると信じています。 私は、アプリケーションがなくなるとは思いません。それは、アプリケーションの境界を決めることが非常に難しいことと同じ理由からです。 もともと、アプリケーションとは社会的構築物なのです: 開発者グループにとって、アプリケーションとは「コード」 業務部門のユーザにとって、アプリケ
[source and translators] 原文: https://www.martinfowler.com/eaaCatalog/transactionScript.html ビジネスロジックをプロシージャ群によって形成する。各プロシージャはプレゼンテーションからの単一のリクエストを処理する。 解説の全文は『PofEAA』 110 ページを参照。 多くのビジネスアプリケーションは、一連のトランザクションであると考えられる。 トランザクションは情報の集まりを、ある約束事に基づいてまとめられたものとみなし、変更を加えることもある。 クライアントシステムとサーバーシステムとのやりとりには、 一定量のロジックが含まれる。 データベースの情報を表示するだけの簡単なロジックもあれば、 検証や計算のために多くのステップを含むロジックもある。 トランザクションスクリプトは、これらすべてのロジックを
[source and translators] 原文: https://www.martinfowler.com/eaaCatalog/activeRecord.html データベースのテーブルやビューの列をラップし、データベースアクセスをカプセル化し、ドメインロジックを追加するオブジェクト 解説の全文は『PofEAA』 160 ページを参照。 データと振る舞いの両方を持つオブジェクト。データの多くは永続的であり、データベースに格納される必要がある。ActiveRecordは、メインオブジェクトにデータアクセス処理を置くという最も明らかなアプローチを採用している。この方法では、全員がデータベースへの読み書きするやり方を知っている。
Redirecting… Click here if you are not redirected.
http://martinfowler.com/bliki/BranchByAbstraction.html 「抽象化によるブランチ」というテクニック1は、ソフトウェアシステムへの大規模な変更を徐々に進めていくときに使われるものだ。 これを使えば、変更がまだ完了していなくても、定期的にシステムをリリースできるようになる。 こんな状況を考えてみよう。システムのかなりの部分が依存しているモジュール(あるいはライブラリやフレームワーク)があって、それをリプレイスしようとしている。 ※Flawed Supplier…欠陥のあるモジュール 抽象化レイヤーを作って、クライアントのコードとモジュールとのやりとりをそこに閉じ込める。 クライアントのコードの中でモジュールを呼び出しているところをすべて書き換えて、この抽象化レイヤーを経由させる。 各クライアントについて、この抽象化レイヤーを使うよう徐々に書き
http://martinfowler.com/bliki/OneLanguage.html 開発における言語は1つだけにするべきか? ソフトウェア開発の際に1つの標準言語に集中することが、ここ10年の間ほぼずっと、エンタープライズ・ソフトウェア界における流行であった。多くの開発組織が、すべての作業をJava(もしくはC#/VB)でこなそうとしている。 その理論的根拠は、開発者が複数の言語に熟練するのは困難だということだ。単一の言語にこだわれば学習の負荷は下がる。とりわけ新人を採用するときにはそう。 まったくの嘘というわけではないが、ほとんど大はずれだ。プログラミング環境ってのは一部は言語だけれど、でも複数の言語やフレームワークについてでもある。大規模フレームワーク、HibernateやStrutsやADOなんかは、単一のホスト言語でプログラミングしていたとしたって、今や1つの言語を学ぶの
http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か? 逆に、そう呼ぶべきでないものは何か?といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt(散乱は負債ではない)」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、パターンカタログの翻訳を行っています。 ※書籍の邦訳とは一切関係ありません。 PofEAAのパターンカタログから読始めるとよいでしょう。 パターンカタログの日本語版 パターンカタログの英日対応表 上記のカタログでは書籍の訳語を踏襲していますが、各ページでは「できるだけ正しい」訳語を使うようにしています。邦訳版のパターン名に関する議論などは、JapanesePatternNamesを参照。 ページ一覧 アクティブレコード アプリケーションコントローラ 関連テーブルマッピング BBS パターンカタログ パターンカタログの比較表 パターンカタログ(日本語) クラステーブル継承 クライアントセッションステート 粗粒度ロック 具象テーブル継承 データマッパー データ転送オブジェクト データベースセッションステート
http://martinfowler.com/bliki/CatastrophicFailover.html (最後の部分を更新) 最近のアプリケーション サーバの広告には、 「フェールオーバー クラスタ機能を提供します」と書かれてある。 クラスタリングはアプリケーションの信頼度を向上してくれる。 使用しているサーバの1台が落ちてしまっても、 顧客用のサーバはまだ他にもあるからだ。 フェールオーバーはさらに信頼度を向上してくれる。 やり取りの最中にサーバが落ちてしまっても、 クラスタによってやり取りが他のサーバに移されるからだ。 これがどのような問題になるのだろうか。 リクエストによっては、 知らない間にサーバ ソフトウェアのバグをつついてしまい、 サーバをクラッシュさせることもある。 このとき、フェールオーバー機能が作動していると、 その致命的なリクエストは他のサーバに移動し、 サーバ
http://martinfowler.com/bliki/PresentationDomainSeparation.html 最も有用な設計原則に、 プログラム(ユーザーインターフェイス)のプレゼンテーション層とその他の機能をうまく分ける、というのがあります。 私はこれを発見して以来、ずっと慣行しています。 長い間これを使ってきて、いくつものメリットを発見しました。 プレゼンテーションロジックとドメインロジックが分かれていると、理解しやすい 同じ基本プログラムを、重複コードなしに、複数のプレゼンテーションに対応させることができる ユーザーインターフェイスはテストがしにくいため、それを分離することにより、テスト可能なロジック部分に集中できる スクリプト用のAPIやサービスとして外部化するためのAPIを楽に追加できる(選択可能なプレゼンテーション部分で見かける) プレゼンテーション部分のコー
[source and translators] PofEAAのパターンカタログの邦訳名/原著名の対応です。以下の一覧にあるパターン名の後ろのカッコ内の数字は邦訳のページ番号です。原文のページ番号はPofEAAのパターンカタログを参照してください。 邦訳版のパターン名に関する議論などは、JapanesePatternNamesのページを参照。 「ドメインロジックパターン」(Domain Logic Patterns): トランザクションスクリプト(TransactionScript) (115), ドメインモデル(DomainModel) (123), テーブルモジュール(TableModule) (133), サービスレイヤ(ServiceLayer) (142). 「データソースのアーキテクチャに関するパターン」(Data Source Architectural Patterns):
以下の文章は、Martin Fowler による Developing Patterns of Enterprise Software の日本語訳である。 以下は、個人的な調査で集めたエンタープライズ ソフトウェア開発に関するパターンのカタログである。 最終更新日: 2005/2/19 近年、小粒だが有用なエンタープライズ システム開発パターンが記述されてきている。 このページでは、特筆すべきパターンや、パターンの相互作用などについて述べていく。 各パターンに関するより詳しい情報については、 PatternShareを参照するとよいだろう。 ここはマイクロソフト パターン グループにより運営されており、 独自にパターン カタログの体系付けを行っている。 パターン作者を結びつける公式的な組織は存在していない。 しかし、私たちは非公式な関係で結びついている——お互いの作品をレビューしあっている
http://www.martinfowler.com/bliki/FluentInterface.html 2005/12/20 数ヶ月前、Eric Evansと一緒にあるワークショップに参加した。 そこで彼がとあるインターフェースのスタイルについて語ったのだが、 我々はそれを「流れるようなインターフェース(fluent interface)」と名づけることにした。 一般的なスタイルではないが、もっと評価されるべき代物だ。 おそらく例を示したほうがいいだろうから、そうしてみることにする。 一番簡単な例は、EricのtimeAndMoneyライブラリだろう。 時間の間隔を作るには、通常は、以下のようにする。 TimePoint fiveOClock, sixOClock; ... TimeInterval meetingTime = new TimeInterval(fiveOClock,
以下の文章は、Martin Fowler による Domain Logic and SQLの日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの(rich SQL queries)を用いるので悪しからず。 エンタープライズアプリケーション(訳注:以下、EA)構築に関する本(私の近著『P of EAA』など)を読むと、ロジック
これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真ドメインモデル」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな振る舞いしかない、ということに気づくと思います。 ドメインのロジックをドメインオブジェクトの中に入れないという設計ル
http://martinfowler.com/bliki/DeploymentPipeline.html 2013/5/30 自動ビルドやテスト環境を構築するときに、問題になることがある。そのひとつが、 ビルドを高速にしてフィードバックをすぐに得られるようにしたいけれども、包括的なテストをしようとすると時間がかかるということだ。 デプロイメントパイプラインは、ビルドをいくつかのステージに分割してこの問題に対処する。 ひとつのステージを通過するごとに信頼性が増すが、それぞれのステージにはそれなりの時間がかかる。 前半のステージで大半の問題をあぶり出してしまって素早くフィードバックし、 後半ではじっくり時間をかけた調査をする。 デプロイメントパイプラインは継続的デリバリーの肝となるものだ。 一般的に、デプロイメントパイプラインの最初のステージは、 何らかのコンパイルをしてバイナリを作るという
http://martinfowler.com/bliki/SacrificialArchitecture.html 会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたをどんな気持ちにするだろう? 多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 私たちは偉大なコードとして長命なソフトウェアを思い描くことが多い。私は 1980 年代に生まれたエディタでこの記事を書いている。ソフ
以下の文章は、Jason YipによるIt’s Not Just Standing Up: Patterns of Daily Stand-up Meetingsの日本語訳である。Jasonの許可を得て、ここに掲載する。 立ってやるのはミーティングの時間を短くするためだ 朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル(訳注:ハドルとは群になって集まること)、朝のロールコール(訳注:ロールコールとはメンバが順番に答えていく方式)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、その
http://martinfowler.com/bliki/TestCoverage.html 「テストカバレッジ(コードカバレッジ)の目標値はどれくらいがいいのか?」という質問とか、コードカバレッジの高さの自慢とかを、ときどき耳にする。でも、大事なポイントを外している。コードカバレッジは、コードのテストされていない部分を発見するための有用なツールである。ただテスト自体がどれだけ良いかという指標としては、テストカバレッジはほとんど役に立たない。 二つ目の例を先に検討してみよう。「カバレッジが87%以上じゃないと本番には入れない」というようなことをやっているところも多いみたいだ。「TDDやっているならカバレッジが100%があたりまえ」という言葉を聞くこともある。賢人が言った: カバレッジが高いことを期待する。マネージャがそう期待することもある。でも微妙な違いがある。 – Brian Mari
ここは、Martin Fowler's Blikiの日本語翻訳サイトです。Martin Fowler氏本人の許可を得て公開しています。データはGitHubで管理していますので、どなたでも翻訳に参加することが可能です。 ※現在、移行中につき、Markdown形式になっていないものが多々あります……。PRいただけると大変ありがたいです。 API design / agile / agile adoption / agile history / application architecture / application integration / bad things / build scripting / certification / clean code / collaboration / computer history / conferences / continuous deliv
このページを最初にブックマークしてみませんか?
『Martin Fowler's Bliki (ja)』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く