回答編集履歴
4
ニュアンス変更
answer
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
https://www.reddit.com/r/ExperiencedDevs/comments/1gpfn6x/if_discord_reddit_twitter_and_uber_dont_use_ddd/
|
|
5
5
|
|
|
6
6
|
例えば、主要フレームワークの中でSpringはDDDを試しやすいと言われているのですが、それでも純粋なDDDを採用すると破城する（主要な書き方から外れる）ところがあるので、柔軟に設計する必要があります。つまり、DDDの良いところは採用して、フレームワークと合わないところは採用しない（厳密な正解を求めない）柔軟さが必要です。
|
|
7
|
-
※ Railsなどは、意図的に非DDDにしているらしく、特定フレームワークとは相性が良くありま
|
|
7
|
+
※ Railsなどは、意図的に非DDDにしているらしく、特定フレームワークとは相性が良くないという問題もあります
|
|
8
8
|
|
|
9
9
|
DDD自体は元々具体的なコードとは結びついていないので、フレームワークに応じて解釈する必要があるのですが、優秀なAIという部下に任せてしまうというのもアリかと思いました。（人間でもそうなのですが、実装の細かい指示をするよりは、方向性を示した方が上手くいくことが多いです）
|
|
10
10
|
|
3
誤字訂正
answer
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
DDDの設計概念は好きな人が多いと思うのですが、海外では主流ではない（知識としては良いが実務では使っていない）ということもあり、おそらく完璧なDDDを実践できている人は少ないと思われます。
|
|
4
4
|
https://www.reddit.com/r/ExperiencedDevs/comments/1gpfn6x/if_discord_reddit_twitter_and_uber_dont_use_ddd/
|
|
5
5
|
|
|
6
|
-
例えば、主要フレームワークの中でSpringはDDDを試しやすいと言われているのですが、それでも純粋なDDDを採用すると破城する（主要な書き方から外れる）ところがあるので、柔軟に設計する必要があります。つまり、DDDの良いところは採用して、フレームワークと合わないところは採用しない（厳密な正解を求めない）柔軟さです。
|
|
6
|
+
例えば、主要フレームワークの中でSpringはDDDを試しやすいと言われているのですが、それでも純粋なDDDを採用すると破城する（主要な書き方から外れる）ところがあるので、柔軟に設計する必要があります。つまり、DDDの良いところは採用して、フレームワークと合わないところは採用しない（厳密な正解を求めない）柔軟さが必要です。
|
|
7
7
|
※ Railsなどは、意図的に非DDDにしているらしく、特定フレームワークとは相性が良くありません
|
|
8
8
|
|
|
9
9
|
DDD自体は元々具体的なコードとは結びついていないので、フレームワークに応じて解釈する必要があるのですが、優秀なAIという部下に任せてしまうというのもアリかと思いました。（人間でもそうなのですが、実装の細かい指示をするよりは、方向性を示した方が上手くいくことが多いです）
|
2
一部訂正
answer
CHANGED
|
@@ -3,8 +3,8 @@
|
|
|
3
3
|
DDDの設計概念は好きな人が多いと思うのですが、海外では主流ではない（知識としては良いが実務では使っていない）ということもあり、おそらく完璧なDDDを実践できている人は少ないと思われます。
|
|
4
4
|
https://www.reddit.com/r/ExperiencedDevs/comments/1gpfn6x/if_discord_reddit_twitter_and_uber_dont_use_ddd/
|
|
5
5
|
|
|
6
|
-
例えば、主要フレームワークの中でSpringはDDDを試しやすいと言われているのですが、それでも純粋なDDDを採用すると破城する（主要な書き方から外れる）ところがあるので、柔軟に設計する必要があります。つまり、DDDの良いところは採用して、フレームワークと合わないところは採用しない
|
|
6
|
+
例えば、主要フレームワークの中でSpringはDDDを試しやすいと言われているのですが、それでも純粋なDDDを採用すると破城する（主要な書き方から外れる）ところがあるので、柔軟に設計する必要があります。つまり、DDDの良いところは採用して、フレームワークと合わないところは採用しない（厳密な正解を求めない）柔軟さです。
|
|
7
|
-
|
|
7
|
+
※ Railsなどは、意図的に非DDDにしているらしく、特定フレームワークとは相性が良くありません
|
|
8
8
|
|
|
9
9
|
DDD自体は元々具体的なコードとは結びついていないので、フレームワークに応じて解釈する必要があるのですが、優秀なAIという部下に任せてしまうというのもアリかと思いました。（人間でもそうなのですが、実装の細かい指示をするよりは、方向性を示した方が上手くいくことが多いです）
|
|
10
10
|
|
1
一部訂正
answer
CHANGED
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
例えば、主要フレームワークの中でSpringはDDDを試しやすいと言われているのですが、それでも純粋なDDDを採用すると破城する（主要な書き方から外れる）ところがあるので、柔軟に設計する必要があります。つまり、DDDの良いところは採用して、フレームワークと合わないところは採用しないというような柔軟さです。
|
|
7
7
|
（Railsなどは、意図的に非DDDにしているらしく、特定フレームワークとは相性が良くありません）
|
|
8
8
|
|
|
9
|
-
DDD自体は元々具体的なコードとは結びついていないので、フレームワークに応じて解釈する必要があるのですが、優秀なAIという部下に任せてしまうというのもアリかと思いました。（人間でもそうなのですが、細かい指示をするよりは、方向性を示した方が上手くいくことが多いです）
|
|
9
|
+
DDD自体は元々具体的なコードとは結びついていないので、フレームワークに応じて解釈する必要があるのですが、優秀なAIという部下に任せてしまうというのもアリかと思いました。（人間でもそうなのですが、実装の細かい指示をするよりは、方向性を示した方が上手くいくことが多いです）
|
|
10
10
|
|
|
11
11
|
ちなみに仕様駆動開発の場合は、方向性を示しつつも（それだけではなく）検証し、各フェーズで振り返りと改善を行うことが重要とされています。
|
|
12
12
|
https://developer.microsoft.com/blog/spec-driven-development-spec-kit
|