SOA の人気が高まり、エンタープライズアーキテクチャの中心となるのにともない、別の関連分野によって実現される発展に力を注ぎはじめる必要があることが、ますます明らかとなってきている。この視点は、SOA とドメイン駆動設計との関係についての興味深い議論(リンク)によって確認されている。
SOA(リンク) が
一種のアーキテクチャスタイルで、業務を整列させたエンタープライズサービスの概念を促進する企業のビジネスソリューションを設計し、築き上げ、構成する基本的な単位
であるのに対し、DDD(リンク) は
思考方法と優先順位付けで、複雑なドメインをあつかうソフトウェアプロジェクトの進行速度アップを目標としたもの
である。
この議論は、両者の間の見た目の共通点について、Trond Eirik 氏が次のような質問を投げかけたことから始まった。
SOA と DDD という二つの概念について他の人はどう考えているのか。両者は完全に一致するのか、互いに排他的な概念（ DDD をつかうと SOA をつかうことはできなくなるということ）なのか、問題ドメインの異なる部分を解決するものなのか、同じ部分を解決するものなのか？
moffdub からの回答は、SOA と DDD が非常に相互補完的であるとしている。
DDD はデプロイ単位（ひとつのアプリケーション）での開発手法であり、SOA は複数のデプロイ単位を連携させる方法だ。
Ashley Fernandes 氏は両者を融合する別のアプローチを提案している。彼は DDD をビジネスサービスを定義する技術であると考えている。
私は 3D をつかってサービスレイヤを相互に関連付けているが、それは UDDI によって公開された WSDL サービスと非常に近いものだ。だから、3D と SOA はうまく共存する。
Tomas Karlsson 氏は DDD と SOA を連携させた開発における自身の実際の経験について述べている。彼は、純粋な DDD のアプローチから出発し、オブジェクト（ POJO かステートレス Bean ）を作成し、ドメインオブジェクトを実装し、それらをサービスとして他から利用可能にすることを提案している。その結果は、次のようになる。
顧客情報の CRUD 処理のバックエンドを担当する、非常に責任が明確になったサービスができあがる。このようなサービスを早くに準備しておけば、プロジェクトが早期に安定することになるだろう。
Colin Jack 氏によると、SOA と DDD の共存は確かに可能であるが、非常に注意深い実装が要求されるという。特に彼は、たとえば顧客情報を提供するというエンティティサービスの概念が DDD と対立する可能性があると指摘している。
わたしが考える問題点は、DDD ときれいにフィットするエンティティサービスがみあたらないことだ。これらのサービスを凝集のため他から利用できる状態にするだけだとしても、やはり問題はのこる。なぜなら、ドメイン設計は変更されることになるだろうし、凝集をまたがるトランザクションのような基本的な機能をすでに失っているからだ。それらをルーズにすることもできるが、それでも SOA のメリットを得ているといえるだろうか？
Casey Charlton 氏は Ashley 氏に同意しており、Tomas、Colin 両氏のアプローチは非常に粒度の細かいサービスを大量に生み出すことになると考えている。
SOA を低いレベルにまで落とすよりも、ドメインモデル全体をカプセル化した大きなサービスを外部から利用可能にし、それらのサービス間でメッセージングを利用するほうがよいと、わたしは考えている。適切に設計された SOA とはそういうものだ。それ以上に細粒度なレベルでは「粒度の粗いサービス」の原則に違反してしまうし、SOA アーキテクチャのなかに CRUD 処理の存在する余地はない。
Andreas Ohlund 氏は、「 DDD は粒度の粗い SOA サービスのなかにドメインロジックを構築するためのものだ」という Bill Poole 氏(リンク)の言葉を引用し、Casey 氏の意見をサポートしている。
SOA と DDD は確かに同じゴールを目指している。よく設計されたサービスは(参考記事・英語)、その名前が CEO や事業主の面々によく知られていて、そのサービスが何をするものなのかについて事業主が関心をもつものだ。一方で、よく設計されたドメインオブジェクトは、セマンティックなデータモデル、サービスの構築、そしてそれらの間で情報の受け渡しを行うために利用される(リンク)、基礎となる一連のオブジェクトを定義するものである。