InfoQ ホームページ DomainDrivenDesign に関するすべてのコンテンツ
-
システムをマイクロサービスに分解するには
２年前、Vladik Khononov氏とそのチームはマイクロサービスの導入を決定したものの、数ヶ月後に大きな混乱に陥った。システムをマイクロサービスに分解する方法 - さまざまな機能を配置するためのバウンダリを見つけ出す方法を検討することなく、新しいクールなテクノロジに飛びついたことが原因だった。
-
DDD、イベントストーミング、アクターモデルを使用したリアクティブシステムの設計
ドメイン駆動設計（DDD）は、しばしマイクロサービスを取り巻く境界（境界づけられたコンテキスト）を見つけ出すために用いられる。しかし、DDDに含まれるすべてのものがマイクロサービスにとって良いわけではない、とLutz Huehnken氏はベルリンで開催されたmicroxchg 2018のプレゼンテーションのなかで主張した。氏はDDD、イベントストーミング、そしてAkkaを基盤としたLagomフレームワークを使用して、リアクティブシステムをどうやって構築できるかを解説している。
-
QCon London: 非同期イベントアーキテクチャにおけるアクタ導入の可否
マイクロサービスシステムにおける同期型の要求-応答通信は、場合によっては非常に複雑なものになるが、幸いにもイベントベースのアーキテクチャがこれを回避する手段になる — QCon London 2018でのプレゼンテーションで、Yaroslav Tkachenko氏はこのように主張し、イベントアーキテクチャでの自身の経験から、このアーキテクチャでシステムを構築する上でアクタを利用する方法について説明した。
-
DDD Europe 2018カンファレンス参加記
先日アムステルダムで開催された第3回DDD Europe 2018カンファレンスには、700名近い参加者があった。カンファレンスはドメイン駆動設計(DDD)を中心とするもので、基調講演と19のプレゼンテーション、オープンスペースで開催された１トラックを含み、ライブコーディングとハンズオンを重視した17のセッションが行われた。注目すべき講演者はEric Evans、Dave Snowden、Rebecca Wirfs-Brock、Cyrille Martraire各氏などである。
-
ドメインストーリテリングを使ってコンテキスト境界を見つけ出す
ドメイン駆動設計(DDD)による開発では、コンテキスト境界(bounded context)が重要なコンセプトとなる。ドメインストーリテリング(Domain Storytelling)とは、人々とシステムがドメイン内でどのように共同作業するのか、コンテキスト境界を識別する上で使用できるのは何か、どのように連携するのかを見出す手段である — 先日アムステルダムで開催されたDDD Europe 2018で、Stefan Hofer氏とHenning Schwentner氏はこのように説明した。
-
イベントソースシステムにおける過去と未来のイベント
Thomas Pierrain氏がある資産管理会社と新たなプロジェクトを始めた時、重要な要件のひとつとして、現時点で見ると疑問のある判断を下した理由を理解するために、時間を遡ることを可能にする、というものがあった。アムステルダムで先日開催されたDDD Europe 2018でPierrain氏は、時間軸的な課題を持ってイベントソースシステムを構築した自らの経験について論じた。
-
CQRSとイベントソーシングでシステムを構築する
CQRSとイベントソースシステムに関する議論の末にMichiel Overeem氏が達した結論は、イベントソースシステムに従事する人々の多くはそのシステムを理解せず、問題へのアプローチ方法も分かっていない、というものだ。これが氏にとってこの種のシステムを構築する方法を探求的に研究するきっかけになったと、氏は、先日アムステルダムで開催されたDDD Europe 2018カンファレンスで説明した。
-
Eric Evans氏の基調講演より - ドメイン駆動設計を実践するには
アムステルダムで開催されたDDD Europe 2018で基調講演を行ったEric Evans氏にとって、ソフトウェア開発で重要なのは探求と実践だ。DDD(ドメイン駆動設計)の戦略的パターンに取り組んでいる氏にとって、しかしながら本当の意味で興味があるのは、複雑なドメインに対する新たな思考法、すなわち思考の箱(mental box)から抜け出して新たなコンセプトを見出す方法だ。
-
イベントアーキテクチャを選択する
分散システムの設計において、おそらくはマイクロサービスに基づいたイベントアーキテクチャを検討する場合、利用可能なモデルとテクノロジはいくつかある。アーキテクチャの実装方法を選択する時、そのおもな要因は非機能要件である - さまざまなイベントアーキテクチャのスタイルを説明した先日のブログ記事で、David Dawson氏はこのように主張している。
-
ドメイン駆動設計のガイドライン: Capture - Embed - Protect
ソフトウェア設計と開発のガイドラインとしてドメイン駆動設計(DDD)の中核的な哲学とプラクティスを用いる場合、それはCapture — Embed — Protectという３つの原則にまとめることができる — 今年のDDD eXchangeカンファレンスで行なったプレゼンテーションの中で、Steven A. Lowe氏はこのように主張した。我々は、肯定的な行動を取るに十分な理解を得ることでドメインモデルを捕捉(Capture)し、コードや会話の中にそれを埋め込み{Embed)、他ドメイン、特に技術的なドメインによる改変から保護する(Protect)のだ。
-
イベントベースのシステムにおけるプロセスマネージャー
ドメインが保持する変更を通知するためにイベントを発行することは、異なるドメイン同士を互いから疎結合に保つが、そこに本当にイベントの論理フローが存在するのであれば、フローは暗黙的なものとなり追跡するのが難しくなってしまう。より良い解法はプロセスマネージャーパターンを用いてプロセスの全てを追跡し続けることである、とBernd Rücker氏は述べた。
-
ドメインロジックにおける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における発表で述べた。