CAD Development Roadmap

目次案

1. 概要
2. 全体アーキテクチャマップ
3. 機能領域カタログ
4. 推奨実装順序
5. 統合優先順位
6. Drafting から cad-core への移行方針
7. 機能依存関係マップ
8. リスクと注意点
9. 最終到達像
10. 実装運用ガイド

1. 概要

この roadmap の目的

• 既存の途中実装 CAD を、cad-core を中心としたドメイン駆動構造へ段階的に統合する。
• 機能追加とリファクタリングを同時進行させる際の、依存順序と統合ポイントを明確化する。
• UI 実装中心の開発から、ドメイン中心の継続可能な開発体制へ移行する。

現在の状態

• 既設 CAD の機能は拡張されているが、UI コンポーネント層にロジックと API 呼び出しが残る。
• cad-core には interaction、semantic、versioning、permissions、plugin などの中核が揃いつつある。
• Drafting 側との責務重複が残り、二重実装が発生しやすい。

今後の方針

• 新規開発は原則 cad-core に集約する。
• Drafting は互換レイヤーとして最小化し、機能単位で撤去する。
• persistence、permissions、collaboration、plugin を platform 層として分離する。

2. 全体アーキテクチャマップ

レイヤー構成

レイヤー	主責務	主な内容
Core Domain	CAD ドメインの唯一の真実	geometry、entity、document、history、constraints、version semantics
Geometry and Query	幾何計算と探索	intersections、projection、hit test、snap、spatial index
Interaction and Editing	編集操作の実行	selection、box selection、transform、grip、vertex editing、undo redo
Document Semantics	図面概念の意味層	blocks、dimensions、annotations、hatch、layout、paper space
Rendering and Plot	表示と出力	2D renderer、将来 3D、plot pipeline、exporters
Collaboration and Review	共同作業文脈	comments、review status、diff overlay、review session
Persistence and Sync	保存と同期制御	serializers、repositories、autosave、draft、conflict、revision
Access and Permissions	認可制御	roles、sharing、effective permission、policy guard
Extensibility and Plugins	拡張基盤	registries、manifest、capability、lifecycle、host bridge
UI and Editor	表示と入力のみ	toolbar、sidebar、viewport、status 表示、command dispatch

重要原則

• cad-core は API 通信を持たない。
• UI は backend DTO を直接構築しない。
• render primitive は semantic entity の派生結果として扱う。
• history と versioning を別概念として維持する。

3. 機能領域カタログ

#	機能領域	目的	依存基盤	主要責務	関連レイヤー	状態	統合時の注意
1	アーキテクチャ / cad-core 中心設計	ドメイン中核の確立	TS モジュール境界	依存方向統制、公開 API 明確化	Core Domain	統合中	UI 直結実装を逆流させない
2	internal model / document / editor state	永続状態と一時状態の分離	entity type、viewport model	semantic document と editor transient の分離	Document Semantics	追加済み	保存時に editor transient を混入させない
3	DXF adapter / import	外部 CAD 互換	parser、entity mapper	DXF から internal model へ変換	Adapters	追加済み	adapter にドメイン規則を埋め込み過ぎない
4	renderer 分離（2D / 将来3D）	表示責務分離	viewport transform	semantic から描画データ導出	Rendering	統合中	renderer に編集ロジックを入れない
5	snap	作図精度向上	geometry、viewport、hit test	スナップ候補算出、モード制御	Geometry and Query	追加済み	world と screen 座標を混同しない
6	hit test	操作対象決定	geometry、spatial index	entity 単位ヒット判定	Geometry and Query	追加済み	描画見た目依存で判定を壊さない
7	selection	選択状態管理	hit test	単体選択、複数選択、hover	Interaction	追加済み	UI 状態と document を混在させない
8	box selection	範囲選択	selection、geometry	窓選択、交差選択	Interaction	追加済み	画面拡縮時の判定精度維持
9	drag / transform	移動変形編集	selection、history	move、rotate、grip drag	Interaction	追加済み	undo 単位を transaction で統一
10	grip edit	形状直接編集	selection、hit test、transform	grip 生成、編集反映	Interaction	追加済み	grip 情報を永続化しない
11	vertex editing	頂点編集	polyline model、history	頂点追加削除移動	Interaction	追加済み	topology 一貫性を保つ
12	undo / redo	操作の可逆性	history engine	履歴管理、巻き戻し	Interaction	追加済み	versioning と責務混同しない
13	transaction / command grouping	複合操作の一貫性	history command	コマンド束ね、atomic commit	Interaction	追加済み	UI 単位とドメイン単位を合わせる
14	spatial index	大規模図面性能	bounds 計算	hit test と query 高速化	Geometry and Query	追加済み	編集時のインデックス更新漏れ
15	block / insert	再利用図形管理	document model、transform	block 定義、insert 解決	Document Semantics	追加済み	展開結果と定義の不整合回避
16	dimension / annotation	寸法注記表現	style model、renderer	寸法生成、注記表示、style	Document Semantics	追加済み	plot/export との整合
17	constraint / parametric editing	制約駆動編集	solver、entity refs	制約評価、拘束維持	Document Semantics	統合中	solver と直接編集の競合制御
18	hatch / fill / pattern	面表現	boundary 解決、triangulation	hatch style、境界判定、描画	Document Semantics	追加済み	DXF/export でパターン互換注意
19	plot / export / printing	出力基盤	layout、style、renderer data	world to page、plot style、export	Rendering and Plot	統合中	画面描画と印刷仕様を分離
20	layout / paper space / title block	図面紙面化	block、plot	model/paper 管理、viewport、title block	Document Semantics	追加済み	activeSpace 切替と履歴整合
21	collaboration / comment / review	レビュー作業	anchors、review status	thread、marker、review state	Collaboration and Review	追加済み	geometry payload と混在保存しない
22	versioning / snapshot / diff review	版管理と差分	snapshot model、diff engine	snapshot、version metadata、diff session	Collaboration and Review	追加済み	undo redo と統合しない
23	permissions / roles / project sharing	安全な権限制御	access policy、sharing	effective permission、guard	Access and Permissions	追加済み	UI 判定のみで制御しない
24	plugin / extension architecture	拡張可能性	registries、capability	plugin lifecycle、host bridge	Extensibility and Plugins	追加済み	private API を公開しない
25	API / backend synchronization / persistence	永続化と同期	serializers、repositories、sync manager	load save、autosave、draft、conflict	Persistence and Sync	統合中	UI 直 API 呼び出しを段階排除

4. 推奨実装順序

Phase 1: cad-core 基盤

• 対象: 1, 2, 3, 4
• ゴール: ドメインモデルと adapter 境界の固定
• 完了条件:
  • cad-core 公開 API が定義済み
  • import/export 基本経路が domain 経由

Phase 2: interaction and editing 基盤

• 対象: 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
• ゴール: 編集操作の一貫化と性能確保
• 完了条件:
  • 編集操作が history transaction 経由
  • 大規模図面で操作遅延が許容範囲

Phase 3: document semantics

• 対象: 15, 16, 17, 18
• ゴール: CAD 意味層を UI から独立
• 完了条件:
  • block、dimension、hatch、constraint が semantic 化
  • renderer は semantic から派生表示

Phase 4: output, layout, plotting

• 対象: 19, 20
• ゴール: model space と paper space を統合出力
• 完了条件:
  • plot pipeline が layout aware
  • export が renderer と疎結合

Phase 5: collaboration, review, versioning

• 対象: 21, 22
• ゴール: 共同作業と変更追跡の標準化
• 完了条件:
  • comment/review と diff session の整合
  • snapshot と review の接続方針確定

Phase 6: permissions, persistence, platformization

• 対象: 23, 24, 25
• ゴール: 企業運用可能な CAD platform 化
• 完了条件:
  • repository と sync manager の本稼働
  • plugin と permissions の境界統制

5. 統合優先順位

既設CADから cad-core へ優先統合

1. save/load 経路の serializer/repository 化
2. selection、transform、history の command 化
3. layout、plot、export の pipeline 化

Drafting から除去しやすい領域

• Symbol 保存 API 呼び出し
• autosave のタイマー制御
• DTO 変換ロジック

二重実装になりやすい領域

• hit test と snap
• layer visibility/lock など editor 設定
• layout normalize ロジック

統合リスクが高い領域

• constraint solver と既存手動編集の競合
• versioning と collaborative review の整合
• permissions の UI 判定と backend 判定の不一致

6. Drafting から cad-core への移行方針

基本方針

• cad-core を唯一の中核実装にする。
• Drafting は旧仕様互換層として段階的に解体する。
• 新規機能は原則 cad-core へ実装する。
• UI、interaction、renderer、persistence は cad-core 公開責務のみ使用する。

移行ステップ

1. API 呼び出しを persistence/repositories に移動
2. payload 変換を serializers へ移動
3. interaction ロジックを command transaction に寄せる
4. Drafting 内ドメインロジックを削除し facade 呼び出しへ置換
5. 参照ゼロ化後に Drafting 実装を撤去

7. 機能依存関係マップ

主要依存

• snap は hit test、geometry、viewport に依存
• hit test は spatial index、entity bounds に依存
• selection は hit test と history transaction に依存
• grip edit は selection、hit test、transform、history に依存
• vertex editing は transform、history、constraint に依存
• block/insert は internal model、transform、renderer、hit test、spatial index に依存
• dimension/annotation は style model、renderer、plot/export に依存
• hatch は geometry、boundary、renderer、export adapter に依存
• layout は plot、export、block、annotation に依存
• versioning は persistence、collaboration、review に接続
• permissions は mutation、export、version、plugin 実行に接続
• plugin は registries、permissions、transaction、persistence に接続

依存方向ルール

• UI から Core Domain へは facade 経由のみ
• Core Domain から API へは依存しない
• Plugin は capability 制御された host API のみ使用

8. リスクと注意点

• Drafting と cad-core の責務混在
  • 対策: ドメインロジックの配置先を cad-core に固定
• semantic entity と render primitive の混同
  • 対策: renderer 入力を derived data に限定
• screen 座標と world 座標の混同
  • 対策: transform ユーティリティを単一路線化
• UI から直接ロジックや API を叩く設計
  • 対策: repository/service 経由の lint ルール化
• history と versioning の混同
  • 対策: undo redo と snapshot を別ストアで管理
• collaboration と geometry の混同
  • 対策: payload と保存先を論理分離
• export と screen renderer の混同
  • 対策: plot pipeline を出力正として統一

9. 最終到達像

• cad-core が唯一のドメイン中核実装
• interaction は command transaction を通じて実行
• renderer は semantic から派生した表示層
• persistence は serializers、repositories、sync manager で分離
• collaboration、versioning、permissions は独立しつつ統合
• plugin は capability 管理下で安全に拡張
• model space、paper space、review、diff、export を統合した CAD platform
• Drafting は撤去済み、または最小互換シェルのみ

10. 実装運用ガイド

PR 単位の推奨

• 1 PR 1 レイヤー変更を原則とする
• domain 変更と UI 変更を同時に大規模実施しない
• adapter と serializer の変更は contract テストを付与

完了判定の共通基準

• domain API の型が明確
• history、permissions、persistence との整合が取れている
• 既存 UI の回帰がない
• 依存方向が architecture map に反していない