概念設計が、その後のコードの命運を左右する

最近、ソフトウェア開発における概念設計の威力と重要さについて人に伝えたい機会が何度かあった。[1] しかし、概念の整理がなぜどのように重要なのか、という一点を取り上げて書かれたものは少ないようで、人に渡すのにちょうどよい文章や書籍が見つからなかったので、このたび私なりに咀嚼して書いてみたい。 そのアプリケーションの世界には、そもそも何が存在するのか。 何と何を同じものとして扱い、何と何を別のものとして扱うのか。 この判断が合っていると、その後の実装は驚くほど素直になる。逆にここを外すと、一つ一つの実装は正しくても、仕様が増えるたびに少しずつ帳尻合わせが必要になる。 まず、一つの小さなECサイトから話を始めよう。 Acme社のECサイトでの出来事 Acme社では、小さなECサイトを作っている。注文には商品ごとの明細があり、その配送状況も確認できる。最初のモデルはこうなった。 type Ord

[mak_in]

実装のコストが下がった今、思想がより大事になるはず。そこまで理解できる開発者は少ない。指示を出せばできる、でも指示を言語化するには現実世界を観測する必要がある、観測から言語化にはフィルター≒思想がいる

[mercenne]

開発者「OrderとFullfilmentを分けましょう。追加工数はかかります」 偉い人「そういう状況は起こらない想定だからやる必要なし」 (数ヶ月後) 偉い人「やっぱやって」

[revert]

とても同意できるし本当に大事だよね。一方で、適切な関心単位に分解することを思いつける人は経験的にはかなり少ない

[moronbee]

概念設計とネーミングは本当に大事。ただ上手い人程ドヤらないし上手くやる程自然に見えるので、その洗練さに気づかれにくい

[tettekete37564]

“概念を正しく切り分けると、それまで「注意して防ぐ」必要があったバグが、そもそも発生しにくくなる。” < これな。ロジックではなくシステムや構造で解決するのが優秀なエンジニアに必要な素養だと思っている

[Eiichiro]

概念設計の大事さは、その通り。 ただこの仕様だと、暗黙の条件分岐になる、再配送と複数配送の区別が難しく、マイページや管理画面でどう見せるか？一番はOrderの変更反映がむずい。とかいろいろ課題がある。

[u_1roh]

例示がとても良い。AIに機能要件だけ渡してもこの手の「概念の切り取り直し」は提案してくれないよね。こういう設計はしばらくは人間の手に残るんじゃないかなぁ。

[awaytabi]

それって概念設計ではなくモデリングでは？

[manimoto]

Fulfillmentの概念すごい。自分ならShippingStatusを1対多に切り出すまでしか浮かばない気がする/「AIが考えてくれる」論あるが、正直初見でFulfillment出してきたら「複雑だからOrderのみで書き換えて」という人多いのではと思う

[north_korea]

個人開発だととりあえず作ってみて、設計し忘れた概念に気づいて既存コードを捨てて書き直すみたいな事がコーディングエージェントのお陰でやりやすくなった

[odan3240]

めちゃわかる。これをするためにドメインへの学習の姿勢を続けたい あと後から必要な概念に気付いたときにリファクタリングでその概念を用意してから新機能実装に入るのが好き

[hitotakuchan]

DDD の（戦術的設計ではなく）戦略的設計の部分がまさにこの内容。そして DDD の書籍でも戦略的設計が重要だと書いてある。

[toaruR]

初見だと、なんでこんなに面倒なことしてるんだろう？ってなりがち(ノ∀`)さーせん

[T-norf]

ソフトウェア開発は専門外で、ちょっとだけやる人種だけど、AIコーディングで気軽にプロトタイピングできるようになり、ここらへんのこうしておけば良かったが、ver1.0の実装で簡単に実現できてスッキリな今日この頃

[chess-news]

それって、jisの定義で言葉を使ってるの？ そういうのないの？

[ducky19999]

Analysis Patterns

[masa8aurum]

よい記事。 ・概念を適切に認識して用語を定義して、使っていくこと。それに適切な名前をつけること。これによってその後のシステムの命運がまるで変わる

[peketamin]

なるほどー！

[Hideshi]

「二つの世界線の違いは、再配送機能の実装力ではない。システムの中に何という概念を置いたか。もっと言えば、現実の出来事をどういう概念で捉えたか。その違いである。」

[nakag0711]

際限なく細かくなっていくから結局はどこまで必要そうか未来予想するしかないしそれは完全には当たらない

[Nihonjin]

「Jackson, D. (2023). 優れたデザインにとってコンセプトが重要な理由」「Alexander, C. (2013). 形の合成に関するノート／都市はツリーではない」「他に、Emacs Lisp や Clojure に触れてきたことも良かったように思う」

[raitu]

現状を正しく把握し抽象概念化してシステムに落とし込む大切さについて

[sgo2]

一見YAGNIの「実際に必要となるまで機能を追加しない方が良い」と相反する様に見えるけど、土台の設計とその上に乗る機能を混同してはいけない

[FreeCatWork]

設計で迷走したらボクが猫パンチで軌道修正してあげるにゃ。任せてにゃ！

[yarumato]

“現実世界では何も複雑なことは起きていない。受注担当は1個の注文を受け、1回目の配送では破損が起き、配送担当は2回届けた。受注と出荷を別と認識していれば、Orderに二つの意味を持たせずとも現実をそのまま表現”

[remonoil]

Amazonとかグローバル企業のシステムを観察するとこういったものが分割されていることが分かる

[Magicant]

練習問題が良くできてる

[uehaj]

概念設計＝人工的なラングの分節というソシュール記号学の工学的応用。概念の正誤基準は現実との鏡像一致でなく実践での摩擦の少なさ。概念は経験の法廷に体系として問われ帳尻合わせが増えすぎた枠は改訂を迫られる

[nguyen-oi]

注文と履行を分ける具体例が分かりやすすぎる。これ理解してない設計に当たると地獄見るわ