Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
原文(投稿日:2009/08/10)へのリンク ソフトウェアアーキテクチャの文書化というのは、企業のアプリケーション開発プロセスにおいて重要である。プロジェクトにおけるアーキテクチャの文書化のニーズを理解する上で重要なことは、アーキテクチャの文書化がプロジェクトのライフサイクルにおいてどんな役割を果たすのか理解することだ。プロジェクトにおいて、アーキテクチャドキュメントを作成する根本的な理由は、コミュニケーションと分析と記録のためである(例えば、ある決定をドキュメントに記録しておくと、時間が経過しても失われることはない)。プロジェクトで作成するアーキテクチャドキュメントの量と種類は、そのプロジェクトで作成するプロダクトのコミュニケーションおよび分析のニーズを反映したものにするべきである。 アーキテクチャドキュメントは、プロジェクトからマネジメントへ、アーキテクトや主任設計者から開発者へ、プ
図1.ユビキタス言語はモデルを表現するのに用いられる唯一の言語でなければならない。チーム内のメンバは誰もが、個別の各用語についてあいまいさの残らない形で合意せねばならず、翻訳する必要がないようにしなければならない。 コードはモデルを表現する主要な形態です。要件なり設計の一部分をとらえる過程においては、それ以外の成果物も必要になるかもしれません。しかし、アプリケーションのふるまいと恒常的に同期しているのはコードそれ自体なのです。このようなモデリングの理想郷は、いくぶん脆弱なエコシステムです。前述したような条件が与えられれば実現は可能ですが、むやみに拡大することはできません。概念的統一性を妥協することなく、モデルを拡大することができる最大の範囲が、コンテキスト("context")と呼ばれています。 境界つきコンテキストに踏み込む ドメイン駆動設計において、コンテキストは次のように定義されてい
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
人間の心に働きかけるというのは大変複雑なことです。 世界中で同じように物事を考える脳は二つとありません。 同じ指紋がけっしてないように、二人の人間が働くスタイルは90パーセントであっても合致しません。このように多くの個々の人間を作り出し、しかも全て違うという自然の摂理は美しいとさえ感じます。しかしビジネスであh目標は全利害関係者にとって “一つであり同じ”なのです。 ここでいう人々とは (a)プロジェクトチームメンバー(b)ビジネスユーザー (c)経営陣及び出資者など様々な立場でプロジェクトに係わる人を意味します。人々はどのプロジェクトでも管理されることが必要なのです。 というのは プロジェクトのゴールに向かって並ばせ、ワークスタイルを統一する ベストなものを引き出す 集中してやる気のある状態にするだからです。 もしプロジェクトの誰もが完璧であれば、どの業界のどんなプロジェクトも失敗するこ
複数のチームが動いているアジャイル環境では、以下の目的を実現するバージョン管理モデルが必要になります。 フェイルファースト フェイルファーストとはコードのコンフリクトや統合での問題を可能なかぎり早期に発見することです 大きな問題を数回のタイミングで修正するよりも、小さな問題を何度も修正していく方が賢明です 常にリリース可能 どんなに悪いスプリント(イテレーション)だったとしても、その成果物は何かしらリリース可能なものでないといけません シンプル このスキームはチームのメンバ全員に毎日使われることになるので、ルールや定型作業は明確かつシンプルでないといけません 紙1枚にまとめた要約図(壁張り用) この図を見て分からないことがあっても構いません。この先を読んでください。 この図を見て分からないことがなくても、この先を読んでください。 この要約図はPDFでもダウンロードできます(DL) バージョ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く