欧州連合（EU）の執行機関である欧州委員会は11月27日（現地時間）、米Appleの「Apple Maps」（マップ）と「Apple Ads」（広告）をDMA（デジタル市場法）の「ゲートキーパー」に指定する検討を開始したと発表した。Appleから、これらのサービスはDMAの基準を満たしているとする正式な反論を受領済みとしている。
DMAは、EU域内市場に大きな影響を与え、強固かつ持続的な市場ポジションを有し、企業と消費者間の重要なゲートウェイを構成するコアプラットフォームサービスを運営する企業に適用される。過去3会計年度において、月間アクティブエンドユーザー数が4500万人以上、年間ビジネスユーザー数が1万人以上のサービスがゲートキーパーの指定対象だ。
欧州委員会は今後45営業日以内に、Appleのマップと広告をゲートキーパーのリストに追加するかどうかを決定する。ゲートキーパーとされた場合、Appleは6カ月以内に各サービスをDMAに完全準拠させる必要がある。
⇧ とりあえず、
『EU域内市場に大きな影響を与え、強固かつ持続的な市場ポジションを有し、企業と消費者間の重要なゲートウェイを構成するコアプラットフォームサービスを運営する企業』
の定義が謎過ぎるのだが、おそらく、
という構造になるのだろうけど、実質、「アメリカ合衆国」の「企業」が対象となることがほとんどな気がしますな...
ちなみに、「DMA（デジタル市場法）」はというと、
デジタル市場法（デジタルしじょうほう、英: Digital Markets Act、略称: DMA）は、大企業の市場支配力の濫用を防ぎ、新規参入を可能にすることで、欧州のデジタル市場における競争の高度化を図ることを目的とする、欧州連合 (EU) の規則である。指定されたゲートキーパーの義務を定め、違反した場合には、全世界売上高の10%を上限とする罰金などの制裁措置が講じられる。
この規制の対象となるのは、欧州連合内で運営されている最大規模のデジタルプラットフォームである。これらのプラットフォームは、一部のデジタル分野において市場で「持続的な」地位を占めていることや、ユーザー数、売上高、資本金などに関する一定の基準を満たしていることから、「ゲートキーパー」とも呼ばれている。
ゲートキーパーのリストはまだ発表されていないものの、「ビッグテック」、つまりGAFAM（グーグル、アマゾン、フェイスブック、アップル、マイクロソフト）がこの法律の主要な対象になる可能性が高いが、それだけには限られない。
デジタル市場法とデジタルサービス法は対になっており、両規則ともにデジタル単一市場戦略 (DSA戦略) の一環で制定され、EU域外の大規模デジタル・プラットフォーム事業者に対する規制を目的とする。
欧州委員会は、「勝者がすべてを手にする」という構図がしばしば見られる、高度に集中したデジタル欧州市場において、公正な競争水準（公平な競争の場）を保証することを目指している。
⇧ と謳っているのだが、効果のほどを統計して公開して欲しいですな...
デジタル市場法の目的
デジタル市場法は、特にビッグ・テック企業を対象としている。DMAは、おそらくはApple、Google、Facebook、Amazonを含む、ユーザー数、資本金、市場支配力、売上高に応じた特定のプラットフォームを「ゲートキーパー」として分類し、新たな義務を課すことを提案した。大企業が市場支配力を乱用することを防ぎ、中小企業や新規参入者が市場に参入できるようにすることを目的としている。
⇧ 上記によると、
- 中小企業
- 新規参入者
の「市場」の参入を促進することを目的としているようなのだが、どれほどの効果が出ているのかを可視化して欲しいところですな。
アプリケーションのパッケージ構成、結局どうすれば良いのか...
「Java」向けの「オープンソース」な「アプリケーションフレームワーク」として、「デファクトスタンダード」な存在になっていると言っても過言ではないと思われる「Spring Framework」は「Spring」プロジェクトの内の1つですと。
Spring Framework は、Javaプラットフォーム向けのオープンソースアプリケーションフレームワークである。単に Spring とも呼ばれる。ロッド・ジョンソンが自著 Expert One-on-One J2EE Design and Development（Wrox Press、2002年10月）と共にリリースしたのが最初である。
で、「Spring」プロジェクトの内の1つとして「Spring Boot」もありますと。
Spring Boot is an open-source Java framework used for programming standalone, production-grade Spring-based applications with a bundle of libraries that make project startup and management easier.
Spring Boot is a convention-over-configuration extension for the Spring Java platform intended to help minimize configuration concerns while creating Spring-based applications.
ちなみに、「Spring」プロジェクトは、
⇧ 2025年11月29日（土）時点で、「Git」の「Repository」の数としては、86 個存在するっぽいのよね。
前置きが長くなりましたが、「Spring Boot」については、2025年11月に「バージョン」が「4.0.x」のものが公開されてましたと。
で、「X（旧：Twitter）」で「喧喧囂囂（けんけんごうごう）」と「侃侃諤諤（かんかんがくがく）」のどちらとも言い難いのだが、話題になっていたのが、「X（旧：Twitter）」で紹介されている「一般的な」と形容されている「アプリケーション」の「パッケージ」の「構成」についてですと。
公式のドキュメントが勝手に更新されていないとすると、
⇧ 上記で旧バージョンのドキュメントも確認できるのだが、「バージョン」が、
- 2.0.0～
- 3.0.0～
- 4.0.0～
については、「パッケージ構成」についてのスタンスは変わっていない模様。
なのだが、「バージョン」が「1.0.0～」については、
⇧ 上記にある通り、「パッケージ構成」が変わっている...
このあたり、「Spring Boot」側のドキュメントで、「設計思想」や「意図」が全く説明されていないので、謎なのよね...
致し方ないので、「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
📄 パッケージ分けスタイル一覧
| No | スタイル／構成思想 | 概要／特徴 |
|---|---|---|
| 1 | レイヤー分割 (Layered / Layer‑by‑Layer / 3‑Tier 等) | 技術責務ごとに層 (UI, ビジネスロジック, 永続化／データアクセス など) を分離し、それぞれに対応するパッケージ／モジュールを置く構成。層ごとの責務が明確。 |
| 2 | 機能／ドメイン単位分割 (Package‑by‑Feature / Package‑by‑Domain) | ビジネスの「機能 (feature)／ドメイン (domain)」ごとにパッケージを切り、その機能に必要なすべてのクラス（モデル／サービス／コントローラなど）をその中に集約する構成。機能ごとにまとまりが見え、機能追加・変更がしやすい。 |
| 3 | ドメイン単位 × レイヤー分割 (Vertical‑Slice / Feature‑then‑Layer / ハイブリッド) | 上記のドメイン単位分割の中で、さらに層 (レイヤー) ごとにパッケージを切る。つまり、機能ごとに「UI／サービス／DB／モデル」などを持つ。ドメインごとの独立性と技術責務の分離を両立する構成。 |
| 4 | ドメイン中心 アーキテクチャ (Hexagonal Architecture / Clean Architecture / Onion Architecture など) | ドメイン (ビジネスロジック) を中心に据え、外部 (UI, DB, 外部サービス) とのやりとりを Port (インターフェース)／Adapter (実装) によって分離。ドメインを技術的依存から守り、柔軟性・テスト性・変更耐性を高める設計思想。 |
| 5 | モジュール分割 (マルチモジュール構成／モジュラーモノリス／モジュール単位分割) | プロジェクトを複数のモジュール (サブプロジェクト) に分割。たとえば「共通モジュール」「ドメイン／モデルモジュール」「永続化モジュール」「サービス (ビジネスロジック) モジュール」「Web/API モジュール」など、責務や粒度でモジュールを分ける構成。将来的な再利用性、独立性、モジュール単位での分割やサービス化を見据えた設計。 |
| 6 | サービス境界による分割 (マイクロサービス構成／サービス単位分割) | アプリケーション全体を単一モノリスとせず、複数サービス (サービスごとに独立したコードベース／パッケージ構造) に分割。各サービスはそれぞれ独立構造 (上記スタイルのどれか) を持ち、サービス間は API やメッセージで連携。大規模・分散システム、独立デプロイ／スケールが必要な場合に有効。 |
🔹 1. レイヤー分割 (Layered)
技術責務 (UI／表示層、ビジネスロジック層、データ永続化層など) を層ごとに分けるので、設計・実装がシンプルで見通しがよく、小〜中規模アプリで扱いやすい。小〜中規模／機能数少なめ。
myapp/
├── build.gradle (または pom.xml)
└── src/
├── main/
│ ├── java/
│ │ └── com/example/myapp/
│ │ ├── controller/ # Web/API 層 (REST コントローラなど)
│ │ ├── service/ # ビジネスロジック層
│ │ ├── repository/ # 永続化／DB アクセス層
│ │ ├── model/ # ドメインモデル／エンティティ／DTO 等
│ │ └── config/ # アプリ設定 (DB, Web, Security など)
│ └── resources/ # 設定ファイル、テンプレート、静的リソース等
└── test/
└── java/… # テストコード
🔹 2. 機能／ドメイン単位分割 (Package-by-Feature / Domain)
各「機能またはドメイン」を単位にコードをまとめるため、「このアプリが何を提供するか」が構造から直感的に理解しやすく、機能単位での修正・拡張がしやすい。機能が複数／将来的な拡張や機能追加の可能性あり。
myapp/
├── build.gradle (または pom.xml)
└── src/
├── main/
│ └── java/
│ └── com/example/myapp/
│ ├── user/ # ユーザ管理ドメイン
│ │ ├── User.java
│ │ ├── UserService.java
│ │ ├── UserRepository.java
│ │ └── UserController.java
│ ├── order/ # 注文管理ドメイン
│ │ ├── Order.java
│ │ ├── OrderService.java
│ │ ├── OrderRepository.java
│ │ └── OrderController.java
│ ├── inventory/ # 在庫管理ドメイン (例)
│ │ └── …
│ └── common/ # 共通機能／ユーティリティ／共通設定など
│ └── …
└── test/
└── java/…
🔹 3. ドメ域 × レイヤー分割 (Vertical‑Slice / Feature‑then‑Layer)
ドメイン (機能) ごとのまとまりを保ちつつ、層 (UI／サービス／DBなど) による責務分離も維持できる — 機能ごとの独立性と全体の整合性のバランスがとりやすい。複数機能・中〜大規模／将来の拡張・保守性・チーム開発を重視。
myapp/
├── build.gradle (または pom.xml)
└── src/
├── main/
│ └── java/
│ └── com/example/myapp/
│ ├── user/
│ │ ├── controller/
│ │ │ └── UserController.java
│ │ ├── service/
│ │ │ └── UserService.java
│ │ ├── repository/
│ │ │ └── UserRepository.java
│ │ └── model/ # entity／DTO 等
│ │ └── User.java
│ ├── order/
│ │ ├── controller/ …
│ │ ├── service/ …
│ │ ├── repository/ …
│ │ └── model/ …
│ └── common/ # 共通設定・ユーティリティなど
│ └── …
└── test/
└── java/…
🔹 4. ドメイン中心 アーキテクチャ (Hexagonal / Clean / Onion など)
この構成により、「ドメイン (ビジネスロジック) を中心に」据え、UI や DB、外部サービスなどの技術的詳細から切り離すことができます。
myapp/
├── build.gradle (または pom.xml)
└── src/
├── main/
│ └── java/
│ └── com/example/myapp/
│ ├── domain/ # ドメインモデル (エンティティ、値オブジェクト、集約など)
│ │ └── … # 例: Order, User, ValueObjects など
│ ├── usecase/ # アプリケーションサービス／ユースケース層
│ │ └── … # 例: CreateOrderUseCase, AuthenticateUserUseCase など
│ ├── port/ # Port (インターフェース) 定義 — ドメインと外部の境界
│ │ ├── input/ # 入力ポート (例: 入力インターフェース)
│ │ └── output/ # 出力ポート (例: リポジトリインターフェース, 外部 API 用インターフェース)
│ ├── adapter/ # Adapter (実装) 層 — 外部との実装 (DB, Web, 外部サービスなど)
│ │ ├── persistence/ # DBアクセス実装
│ │ ├── controller/ # Web / API 実装 (RESTコントローラなど)
│ │ └── external/ # 外部サービス連携やメッセージング、外部 API 呼び出しなど
│ └── config/ # DI 設定、アプリ設定など
└── test/
└── java/…
🔹 5. モジュール分割 (マルチモジュール構成)
このようにモジュールを分割することで、責務ごとの明確な分離、再利用性、独立性が高まり、将来的な分割やサービス化、あるいはライブラリ化にも対応しやすくなります。
myapp-root/ ← 親プロジェクト (settings.gradle または pom.xml)
├── module-common/ # 共通モジュール (ユーティリティ、共通定義、共通設定など)
│ └── src/main/java/com/example/myapp/common/ …
├── module-domain/ # ドメインモデル (エンティティ／モデル) モジュール
│ └── src/main/java/com/example/myapp/domain/ …
├── module-repository/ # 永続化／データアクセス モジュール
│ └── src/main/java/com/example/myapp/repository/ …
├── module-service/ # ビジネスロジック (ユースケース) モジュール
│ └── src/main/java/com/example/myapp/service/ …
└── module-web/ # Web / API モジュール (エントリポイント)
└── src/main/java/com/example/myapp/web/ …
🔹 6. サービス境界による分割 (マイクロサービス構成など)
それぞれのサービスは独立して開発／デプロイ可能で、サービス間通信は API, メッセージングなどを介して行う想定です。複数サービスをまたぐ大規模／分散システム構築向け。
service-user/ ← ユーザ管理サービス (独立リポジトリ or サブプロジェクト) └── (内部構造は任意 — Layered / Feature‑by‑Feature / Hexagonal など) service-order/ ← 注文管理サービス └── (同様に独立構造を持つ) service-inventory/ ← 在庫管理サービス └── … service-common-lib/ ← 各サービスで共通に使うライブラリ／共通モジュール (認証, 共通ユーティリティなど)
🧠 解説と補足
-
多くの現代的な設計では、上記スタイルを単独で使うというより、状況や目的に応じて組み合わせ (ハイブリッド) されることが多いです（例：「モジュール分割」＋「Hexagonal アーキテクチャ」など）。
-
特に、ドメイン中心・ポート／アダプタ型 (Hexagonal / Clean / Onion) は、外部技術の変更やテスト容易性を意識する場合に有効ですが、小規模／単純なアプリには過剰になることがあります。
-
また、機能 (Feature) ごとのパッケージ分割は、機能が増えても可読性・保守性を保ちやすく、変更や新機能追加時の影響範囲を限定しやすいというメリットがあります。
⇧ う～む...、「ChatGPT」氏の整理してくれた「情報」によると、
- Spring Bootのバージョン
- パッケージ構成
の対応については、
| No | Spring Boot バージョン | パッケージ構成 |
|---|---|---|
| 1 | 1.0.0 ～ | レイヤー分割 (Layered) |
| 2 | 2.0.0 ～ | 機能／ドメイン単位分割 (Package-by-Feature / Domain) |
| 3 | 3.0.0 ～ | 機能／ドメイン単位分割 (Package-by-Feature / Domain) |
| 4 | 4.0.0 ～ | 機能／ドメイン単位分割 (Package-by-Feature / Domain) |
⇧ 上記のような分類になるっぽい。
個人的には、「Spring Boot」の「バージョン」が「2.0.0 ～」の「パッケージ構成」は違和感しかないが、「フロントエンド」側の「アプリケーション」の「パッケージ構成」のように「コンポーネント」毎に分ける「設計思想」に近いのかな？
何か、「モデル」とかを「俯瞰」して確認できないのが辛い気がしてしまうが...
そもそも、
⇧ 上記の記事の時に触れた「Python」の「Webフレームワーク」の「FastAPI」の「Controller」の「仕様」だと、「パッケージ構成」によっては、「DRY 原則」から外れたコーディングになってしまったりすると思うのよね...
「DRY 原則」はというと、
Don't repeat yourself（ドント・リピート・ユアセルフ、DRY）は、特にコンピューティングの領域で、重複を防ぐ考え方である。この哲学は、情報の重複は変更の困難さを増大し透明性を減少させ、不一致を生じる可能性につながるため、重複するべきでないことを強調する。
DRY は、Andy Hunt と Dave Thomas の著書 The Pragmatic Programmer (邦題:達人プログラマー) において中心となる原則である。 彼らはこの原則を、データベーススキーマ、テスト計画、ビルドシステムや、ドキュメンテーションにいたるまで非常に幅広く適用している。
DRY 原則がうまく適用されたとき、システムに対するいかなる要素の変更も、論理的に関連のない他の要素の変更にはつながらない。さらに、論理的に関連した要素は予測できる形で統一的に変更され、したがってそれらの変更は同期が取れたものとなる。
⇧ とあるように、「変更容易性」に影響しまくりですな。
であるのだが、「アプリケーション」の「パッケージ」の「構成」については、情報が錯綜している気がしてならない...
世の中の「アーキテクト」と謳っている有識者の方が、推奨する「パッケージ」の「構成」について整理をして情報を発信して欲しいところですな...
「アーキテクト」と謳っている有識者の方は、「内弁慶」にならなくて良いんやで？
弁慶にちなんだ言葉
- 内弁慶、外地蔵
- 「陰弁慶」「炬燵弁慶」とも。あるいは「内弁慶、外鼠」や「内弁慶」のみでも用いられる。身内の中では強気になって威張り散らすが、知らない相手には意気地がなくおとなしい人間のこと。転じて、特定の場面においてのみ威勢を張るさまをもって「-弁慶」等と組み合わせて用いる。
毎度モヤモヤ感が半端ない…
今回はこのへんで。
