アジャイルテストのテスト設計の話 - Test Automation
Incremental test design 昨年度追加されたISTQBのFoundation Level Extension Syllabus Agile TesterのAgile Testing Practicesの項にはテスト設計に関する興味深い記述がある [1]。 Incremental test design: Test cases and charters are gradually built from user stories and other test bases, starting with simple tests and moving toward more complex ones. アジャイルテストのテスト設計の特徴として ユーザーストーリーをテストベースとして用いる事 シンプルなテストケースの追加から始まり、より複雑なものへと変化して行く事 Increme
アーキテクチャ大全 - kawasima
お気に入り / ページネーション / 検討リスト / カテゴリ毎の件数表示 / Conversation threading / オートログイン / 途中保存 / 予約 / 未読管理 / アンケート
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解
![ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed125204d89ae253a4ab2a6c711eff21748ee9c7/height=288;version=1;width=512/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F30489%2F81fcfd95-2ce1-82a8-db69-8618338a5f22.png)
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 / bad things / build scripting / certification / clean code / collaboration / computer history / conferences / continuous deliv
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
アーキテクチャとは？ Grady Booch によると。。。：An Agile Way：オルタナティブ・ブログ
アーキテクチャとは何だろうか？この問いはいろいろな人に聞くといろいろな答えが返ってくるので、「リクルートの面接時に必ず問う」という人もいるはずだ。ソフトウェアと分野に限らなくてもよいし、さらに、システムという分野に限らなくても答えられる。 ぼくの知識の中で、もっともらしいと思われているのが幾つかある。 IEEE1471のアーキテクチャに関するコンセプチャルなフレームワーク これは、図のようなモデルで表現される。これは、かなりフォーマルに「アーキテクチャとは何か？」に答えているようだ。システムには１つのアーキテクチャがあり、１つ以上のアーキテクチャ記述によって記述されており、１つ以上のビューとモデルを含み、ステークホルダと関連している。ステークホルダは１つ以上の関心事をもっており、１つの視点は１つ以上の関心事をカバーしている。。。。。。」と読む（読めるか？）。 RUP RUPは、それ自身、「
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Martin Fowler氏の語る“犠牲的アーキテクチャ"
必要十分な事前設計を行うには