InfoQ ホームページ DomainDrivenDesign に関するすべてのコンテンツ
-
Udi Dahan氏の語るビジネスロジックの再利用とマイクロサービス
再利用(Reuse)はこの13年間，システム開発のほぼすべての事象に対するモットーだった。しかしながら再利用は，少なければ健康的だが，度が過ぎるとダメージを被る，シアン化合物のようなものだ – ロンドンで開催された今年のDDD Exchangeカンファレンスでのプレゼンテーションで，Udi Dahan氏はこのように述べて，ビジネスロジックの面からの視点を提案した。
-
避けるべきDDDの10の失敗
ドメインエキスパートとやりとりをしない、というのが、ドメイン駆動設計 (DDD)でよくある失敗のひとつであり、これを早い段階で修正することで、チームの時間を節約できると、Daniel Whittaker氏は説明する。氏は、DDDの実践の中で、よく出くわす10の失敗についての説明の中で、この点を指摘した。
-
DDD、イベント、マイクロサービス
マイクロサービスを素晴らしいものにするには、ドメイン駆動設計(DDD)が必要であり、5年から10年前に発生した誤ちはDDDによって解決されたが、マイクロサービスの世界でも同じことが起こっている。David Dawson氏はロンドンで開催されたDDD Exchangeの講演でこのように自身の考えを発表した。
-
DDDと”生きたドキュメント"
ドキュメント作成は退屈な作業だ。疎かにされたり，誤った扱いをされることも少なくない。しかしCyrille Martraire氏は，今年ロンドンで開催されたDDD Exchangeカンファレンスでのプレゼンテーションで，ドキュメントとコードをともに改良する新たな考え方として，ドメイン駆動開発(DDD)を使って“生きたドキュメント(living documentaion)”を作る方法を紹介した。
-
DDD、マイクロサービス、境界についてEric Evans氏が語る
マイクロサービスには大きな価値があり、ドメイン駆動設計を実践するための最高の環境を与えてくれると考えている、とEric Evans氏は、ロンドンで開催された、DDD Exchangeカンファレンスのキーノートで講演をした。氏にとっては、イテレーションは良い設計のためにもっとも重要だ。そして、マイクロサービスは良い設計をするためSOA以来の2度目の挑戦だ。
-
ドメイン駆動設計の間違った方向性
アプリケーションは、ドメイン駆動設計 (DDD) を使って構築しなければならないと言われる。実際のドメインモデルは、エンティティか、DTOで構成され、DTOは、ビジネスと基盤となるロジックを組み合わせたものを含むサービスと共に、データとロジックを分離したものだとGabriel Schenker氏は言う。これは、新しいアプリケーションを構築するプロジェクトの初期の段階に当てはまることが多く、Schenker氏は、この主な理由は知識不足だと考えている。
-
ドメイン駆動設計とは - 金融取引アプリケーションを例に
ドメイン駆動設計(DDD)とは，ビジネス目標を達成する上で，ドメインの専門家と開発者，その他の関係者のコラボレーションを重視したソフトウェア開発アプローチだ - Naresh Bhatia氏は，DDDの基本コンセプトをこのような説明で紹介し，金融取引のドメインから，中程度の複雑性を持ったシステムであるBullsfirstを例として選択した。
-
集約、エンティティ、バリューオブジェクト
集約をモデリングして、その集約の中のエンティティから可能な限り多くの振る舞いをバリューオブジェクトに移行しようとするとき、より多くの振る舞いが必要になるにつれ、新しいバリューオブジェクトが必要になる。これは、Paul Rayner氏が集約やエンティティ、バリューオブジェクトなどドメイン駆動設計(DDD)の世界の概念を取り上げた一連のブログ記事の中で推奨していることだ。
-
ドメイン駆動設計のコンテキスト境界間でデータを共有する
ドメイン駆動設計(Domain-Driven Design/DDD)を使って大規模システムの関心事を，それぞれ独自のデータストアを使用するコンテキスト境界{Bounded Context)に分離していると，共通的なデータを共有する必要が生じることが少なくない。それを実現する方法のひとつは，各コンテキストが変更に関するイベントを発行して，他がそのイベントを受信可能にしておくことだ – Julie Lerman氏は先日のMSDN Magazineで，このように説明した。
-
ヘキサゴナルアーキテクチャを探る
階���化システム(Layered System)は，ソフトウェアのメンテナンス性の最大の敵である結合性を回避するための基本的なアーキテクチャスタイルである。"ポートとアダプタ"あるいはヘキサゴナルアーキテクチャは，そのようなアーキテクチャの一例だ。Ian Cooper氏がアーキテクチャスタイル，特にヘキサゴナルアーキテクチャに関して，プレゼンテーションの中で説明している。
-
ドメイン駆動設計とオニオンアーキテクチャ
ドメイン駆動設計(DDD/Domain-Driven Design)とオニオンアーキテクチャを数年前から使い始めたWade Waldron氏は，このコンビネーションによってコード品質が劇的に向上したと考えている。最初はDDDを使い始めたのだが，オニオンアーキテクチャと併用することで，コードがもっと読みやすく，理解しやすく，はるかにメンテナンスしやすいものになることに気付いたのだ。
-
マイクロサービスの配置とビルドのパターン
マイクロサービスを管理するのは、互いに通信しあい、自動的にプロビジョニングするたくさんの小さなシステムの面倒を見ることであり、インフラの自動化が極めて重要だ、とJames Lewis氏は言う。氏はマイクロサービスアーキテクチャがもたらす、増大する運用の複雑性に対処するための方法を共有する中で、このように書いている。
-
Akkaを使ったリアクティブなDDDおよびCQRSベースのアプリケーション構築
DDDとCQRSはコンテキスト境界やトランザクション境界，イベントベース通信といった概念を考慮しながら，スケーラブルなソフトウェアを構築するには最適の組み合わせだ。さらにAkkaを併用することで，企業アプリケーション構築の完全なプラ��トフォームになる - Pawel Kaczor氏は，これらの概念に基づくリアクティブなアプリケーション構築を取り上げた３部シリーズの冒頭を，このようなことばから始めている。
-
SoundCloudのマイクロサービスへの移行
SoundCloudがマイクロサービス型の設計に移行したのは、チームが新しい機能を素早く実装できるようになるために致命的に重要だった。Phil Calçado氏は3連続のブログ記事でそう書いている。この記事では彼らのモノリステックなシステムからの移行についての経験が書かれている。
-
将来に発生することのスケジューリングについてGreg Young氏が語る
メッセージングベースのシステムを考えるとき、将来へのメッセージ送信を遅延させるのはとても強力なパターンだ。このパターンは時間に関する問題に対処するにはとても便利だ。ロンドンで開催されたDDD ExchangeカンファレンスでGreg Young氏はそう語った。