InfoQ ホームページ 方法論 に関するすべてのコンテンツ
-
イベントアーキテクチャを選択する
分散システムの設計において、おそらくはマイクロサービスに基づいたイベントアーキテクチャを検討する場合、利用可能なモデルとテクノロジはいくつかある。アーキテクチャの実装方法を選択する時、そのおもな要因は非機能要件である - さまざまなイベントアーキテクチャのスタイルを説明した先日のブログ記事で、David Dawson氏はこのように主張している。
-
レトロスペクティブに関する初の年次報告書を公開
レトロスペクティブに関する初の年次報告書は、レトロスペクティブが現実世界でどのように使われているのかを深く理解できる。世界中から集まった275を越える調査回答を基にして、結果は、レトロスペクティブがチームコミュニケーションと生産性の改善を導き、信頼の環境を作るのに役立つことを示唆している。主な課題には、議論されるトピックがチームによって解決されず、人々が話すことを快く感じないという事実があった。
-
ドメイン駆動設計のガイドライン: Capture - Embed - Protect
ソフトウェア設計と開発のガイドラインとしてドメイン駆動設計(DDD)の中核的な哲学とプラクティスを用いる場合、それはCapture — Embed — Protectという３つの原則にまとめることができる — 今年のDDD eXchangeカンファレンスで行なったプレゼンテーションの中で、Steven A. Lowe氏はこのように主張した。我々は、肯定的な行動を取るに十分な理解を得ることでドメインモデルを捕捉(Capture)し、コードや会話の中にそれを埋め込み{Embed)、他ドメイン、特に技術的なドメインによる改変から保護する(Protect)のだ。
-
イベントベースのシステムにおけるプロセスマネージャー
ドメインが保持する変更を通知するためにイベントを発行することは、異なるドメイン同士を互いから疎結合に保つが、そこに本当にイベントの論理フローが存在するのであれば、フローは暗黙的なものとなり追跡するのが難しくなってしまう。より良い解法はプロセスマネージャーパターンを用いてプロセスの全てを追跡し続けることである、とBernd Rücker氏は述べた。
-
モバイルおよびWebのテストカバレッジ戦略
すべてのデジタルチャネルにおけるスムーズな機能の実現というユーザの期待に応えるため、開発チームは、各地域の市場でのアプリの使用パターンに合わせたテストを実施する必要がある。本記事ではモバイル市場におけるデータ駆動テストのカバレッジのための、デバイス/OSの組み合わせと、エージングや画面パラメータなどのテスト関連のガイドラインを同時に考慮した方法論と指標を紹介する。
-
ドメインロジックにおけるIf文の危険性
多くのプログラミング言語に見られるif文には、2つの大きな役割がある。ドメインを誤ったデータから守るために入力を検証すること、そして、ドメインのビジネスロジックを処理することだ。残念なことに、私達はビジネスやドメインの観点からロジック中にif文を使用するリスクを管理するためにほとんど時間をかけないことを、Udi Dahan氏は先日アムステルダムで開催されたDDD Europe Conferenceにおいてプレゼンテーションのなかで主張した。
-
DDDにおける重要なパターン
パターンの重要性に関する議論の中で、ドメイン駆動開発以外の部分でも知っておくべき重要なパターンが多く存在し、これらはより良いシステムを設計する支援をしてくれるだろう、とアムステルダムで開催された最近のDDD Europe Conferenceにおける自身の発表の中でCyrille Martraire氏は述べた。
-
ソフトウェア開発に専門分野の重要性を取り戻す
今日の業界紙を読めば，世界中のビジネス側の人たちがITについて，自分たちの足を引く邪魔者だと考えていることが分かるはずだ。この状況を克服するには，私たちが注目点をマシンからドメインへと移し，従事する分野について書籍から学ぶ必要がある - 先日アムステルダムで開催されたDDD Europe Conferenceでのプレゼンテーションの中で，David West氏はこのような指摘をした。
-
Eric Evans氏はDDDが完璧主義者のためのものではないと述べた
ドメイン駆動設計(DDD)の当初からの問題は完璧な設計を求める探求行為であるが、DDDは完璧主義者のものではない。この探求を止めるために、完璧ではないがよく設計されたソフトウェアの開発方法に関する発想を得ることが必要であると、Eric Evans氏はアムステルダムで開催された最近のDDD Europe Conferenceにおける発表で述べた。
-
マイクロサービスを構築する際はイベントとDDDから始めよう
ドメイン駆動設計（DDD）は、私たちが取り組んでいるドメインに設計を近づける優れた技法だが、構造に焦点を当てすぎて、早期に設計を確定してしまうことが多すぎる。これはDDDの意図するところではない。それよりも、Russ Miles氏が「イベント - ファースト」でマイクロサービスを構築する利点を説明するなかで主張したように、ドメイン内のイベントから（設計を）始めるべきである。
-
個々のマイクロサービスではなくプロセスにフォーカスすること
分散システムを基にしたマイクロサービスに取り組む際の成功の鍵は、マイクロサービス自体ではなく、総じて分散プロセスにフォーカスすることだ。サービスは重要性が最も低いパートである、とEric Ess氏は主張した。彼は最近ロンドンで行われたMicroservices Conferenceで、jet.comにおける分散プロセスの監視方法についてプレゼンテーションを行なった。
-
振る舞い駆動開発のアンチパターン
振る舞い駆動開発(BDD)はビジネス関係者とソフトウェア開発者の間のコミュニケーション改善に有効だが，自動化テストの実行にCucumberを使う場合には，Aslak Hellesøy，Matt Wynne，Steve Tooke各氏が先日の議論で説明したようないつかのアンチパターンが存在する。
-
GitLabのアンケート調査から見た開発者のトレンド
スタートアップ362社のソフトウェア専門家を対象に、7月6日から27日にかけて実施したアンケート調査結果をGitLabがリリースした。一番の注目は、最新ツールの利用とコラボレーションの改善に優���度を置いていることだ。セキュリティは優先順位が高いが、81パーセントは準備ができる前にソフトウェアをリリースしていると認めている。
-
Barclayがアジャイル移行で得たもの
スループットの向上，コードの複雑性の低減，運用時の障害減少，デプロイメントサイクルの短縮，チームの幸福度向上 — これらはみな，Barclaysがアジャイル移行で実現したメリットだ。ディシプリンド・アジャイルに基づいて実施された同社の移行は，最初の１年間で800以上のチームにアジャイルを採用するという，アジャイルの実践例として最大級のものである。
-
振る舞い駆動開発の体験
振る舞い駆動開発(Behaviour-Driven Development, BDD)とは，ソフトウェア開発が現代ビジネスの基本であるという認識の下で，ビジネス上のステークホルダとソフトウェア開発者のコミュニケーションの方法を改善するものだ — 先頃公開したブログ記事“experiences working with BDD”の中で，Kevin Smith氏はこのような主張を展開した。