境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab

little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、

[kiririmode]

境界付けられたコンテキストをどう実装に落とし込むか。異なるコンテキストは基本的には別サブシステム。同一にする場合であっても別DBスキーマを検討する

[ntaoo]

良い解説だった

[lefb766]

最近これが発生したので理解深めたい。

[John_Kawanishi]

pic.twitter.com/8z3YNVRw6O 「境界づけられたコンテキスト」それどんなラノベ？（焦

[tsuyok]

境界づけられたコンテキストを、後から考慮するのではなく、はじめから考慮してサービスを作りたい。

[bopperjp]

[microservices]

[efcl]

境界とコンテキスト "1コンテキスト = 1アプリケーション" コンテキスト間の通信について

[wate_wate]

後で

[turanukimaru]

同一モデルの別側面としてみるとDBは同一でもよいと思う。だが別コンテキストでは物理的に分かれる事もあるー例えば配送はタブレットで動くかもしれないーことを考えるとアプリとDBは別にできるなら別にしたい。

[nobuoka]

まさに今 『別コンテキスト同一アプリケーション』 で開発してる。 モジュールを別にしてコンテキストをまたぐ部分はインターフェイスを介したメソッド呼び出しにして、DB は同一インスタンス。