マイクロサービスの分解：ビジネス機能とドメイン
コメンターは正しいです-ここでは、主観的な定義がいくつかあります。しかし、さまざまなアプローチを推論するのに役立ついくつかの原則と概念があります。
コンウェイの法則
これは厳密には元の定義ではありませんが、この区別は コンウェイの法則 を参照すると理解しやすいと思います。
システム（広義に定義）を設計する組織は、その構造が組織のコミュニケーション構造のコピーである設計を生成します。
インバースコンウェイマヌーブル
その考えに従って、 Inverse Conway Maneuver が進化しました：
'Inverse Conway Maneuver'は、チームと組織構造を進化させて、目的のアーキテクチャを推進することをお勧めします。理想的には、テクノロジーアーキテクチャがビジネスアーキテクチャとの同型性を表示することです。
Inverse Conway Maneuverは、より優れたシステム設計を実現するためにConwayの法則を利用するように組織を構築する試みです。
ビジネス能力による分解
これらの概念を理解すると、ビジネス機能による分解は、ビジネスの構造化方法に従ってシステム設計を導くことになると考えることができます。これは、コンウェイの法則と同じです。
このアプローチの長所は、開発チームとビジネス構造ユニット間の整合を確実にするのに役立ちます。欠点は、自動化システムが検討される前に生じたビジネスの非効率性を、システムの設計に焼き付ける可能性があることです。
ドメインによる分解
ドメインドリブンデザイン（DDD）は、基盤となるドメインを推論するための一連のツールと方法論を提供し、ドメインの理解をソフトウェアデザインに反映し、ドメインの理解と成長に合わせてソフトウェアデザインを進化させます。 DDD戦略パターンは、マイクロサービス分解の基礎を形成できる コンテキストマップ の作成をガイドします。
このことから、ドメインによる分解は、プロセスと情報フローの分析に従ってシステム設計を導くと考えることができます。
このアプローチの利点は、何が起こっている（または何が起こる必要がある）現実を厳密にモデル化するシステム設計につながる可能性があることです。うまくいけば、ビジネス構造はすでにこれと一致していますが、一致していない場合は、既存のビジネス組織構造の非効率性が明らかになる可能性があります。
組織構造に影響力を持っている場合、これはInverse Conway Maneuverを活用するための基盤となり、ソフトウェア、開発チーム、およびビジネスユニットを進化させて調整を行うことができます。
そうしないと、システム設計がビジネス機能と整合しなくなる摩擦点が生じてしまう可能性があります。
結論
実際は、どちらのアプローチも相互に排他的ではありません。おそらく、DDDプロセスを通じて明らかにされたビジネス機能と問題ドメインがすでに理解されているため、ビジネス機能との調整のバランスをとろうとする妥協案になるでしょう。
ビジネス機能は、1対1の組織構造を反映していません。実装方法を指定せずに、ビジネスが何をしているか（どのような機能を持っているか）を表します。組織構造は、「方法」/実装の一部です。
ビジネス能力マップが組織構造に従って構造化されている場合は、当然、最初にビジネス能力マップを作成してから、それに応じて組織構造を変更しない限り、これをより綿密に評価する必要があります。
私はドメインとビジネス機能の両方を扱いました。作業しているレベルに応じて、基本的には同じです。