アーキテクチャデシジョンレコード - Martin Fowler's Bliki (ja)
アーキテクチャデシジョンレコード（Architecture Decision Record: ADR）とは、プロダクトやエコシステムに関する重要なひとつの決定を記録および説明する簡潔な文書である。文書は短く、数ページ程度に収め、内容には決定事項、決定の背景、重要な影響を含めなければならない。決定を変更した場合は、文書を修正するのではなく、置き換えた決定にリンクしておく。 ほとんどの文書がそうであるように、ADRの作成にも2つの目的がある。まず、決定の記録である。数か月後あるいは数年後でもシステムが現在のように構築された理由を理解できる。だが、それよりも重要なのが、文書を書くことで考えが明確になる点である。グループの場合は特にそうだ。重要な文書を書くことで、異なる見解が浮かび上がってくる。こうした意見の違いについて議論し、できれば解消することが望ましい。 一般的なルールとして「逆ピラミッド」
LLMは新しい抽象化をもたらす - Martin Fowler's Bliki (ja)
この分野の声が大きい人たちと同じように、私も生成AIシステムがソフトウェア開発にどのような役割を果たすのかについて大きな関心を持っています。LLM（大規模言語モデル）の登場は、アセンブラから最初の高水準プログラミング言語への移行と同じくらい、ソフトウェア開発を大きく変えると思います。その後に開発された言語やフレームワークは、抽象化のレベルや生産性を向上させましたが、プログラミングの本質に同じレベルのインパクトを与えるものではありませんでした。しかし、LLMには最初の移行と同程度のインパクトがあると思います。しかも、単に抽象化のレベルを上げるだけでなく、「非決定的なツールでプログラミングするとはどういうことか」という問いを私たちに投げかけています。 高水準言語は、新しいレベルの抽象化をもたらしました。アセンブラを使うときには、特定のマシンの命令セットを考える必要がありました。単純な操作でさえ
技術的負債の四象限 - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
Patterns of Enterprise Application Architecture - Martin Fowler's Bliki (ja)
Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、パターンカタログの翻訳を行っています。 ※書籍の邦訳とは一切関係ありません。 PofEAAのパターンカタログから読始めるとよいでしょう。 パターンカタログの日本語版 パターンカタログの英日対応表 上記のカタログでは書籍の訳語を踏襲していますが、各ページでは「できるだけ正しい」訳語を使うようにしています。邦訳版のパターン名に関する議論などは、JapanesePatternNamesを参照。 ページ一覧 アクティブレコード アプリケーションコントローラ 関連テーブルマッピング BBS パターンカタログ パターンカタログの比較表 パターンカタログ（日本語） クラステーブル継承 クライアントセッションステート 粗粒度ロック 具象テーブル継承 データマッパー データ転送オブジェクト データベースセッションステート
ドメインモデル貧血症 - Martin Fowler's Bliki (ja)
これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真ドメインモデル」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな振る舞いしかない、ということに気づくと思います。 ドメインのロジックをドメインオブジェクトの中に入れないという設計ル
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Martin Fowler's Bliki (ja)
ここは、Martin Fowler's Blikiの日本語翻訳サイトです。Martin Fowler氏本人の許可を得て公開しています。データはGitHubで管理していますので、どなたでも翻訳に参加することが可能です。 ※現在、移行中につき、Markdown形式になっていないものが多々あります……。PRいただけると大変ありがたいです。 API design / agile / agile adoption / agile history / application architecture / application integration / article / bad things / build scripting / certification / clean code / collaboration / computer history / conferences / contin
プレゼンテーションとドメインの分離 - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/PresentationDomainSeparation.html 最も有用な設計原則に、 プログラム（ユーザーインターフェイス）のプレゼンテーション層とその他の機能をうまく分ける、というのがあります。 私はこれを発見して以来、ずっと慣行しています。 長い間これを使ってきて、いくつものメリットを発見しました。 プレゼンテーションロジックとドメインロジックが分かれていると、理解しやすい 同じ基本プログラムを、重複コードなしに、複数のプレゼンテーションに対応させることができる ユーザーインターフェイスはテストがしにくいため、それを分離することにより、テスト可能なロジック部分に集中できる スクリプト用のAPIやサービスとして外部化するためのAPIを楽に追加できる（選択可能なプレゼンテーション部分で見かける） プレゼンテーション部分のコー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
