nguyen-oi注文と履行を分ける具体例が分かりやすすぎる。これ理解してない設計に当たると地獄見るわ
2026/08/15 08:09★
mak_in実装のコストが下がった今、思想がより大事になるはず。そこまで理解できる開発者は少ない。指示を出せばできる、でも指示を言語化するには現実世界を観測する必要がある、観測から言語化にはフィルター≒思想がいる
2026/08/15 08:15★★★★★
revertとても同意できるし本当に大事だよね。一方で、適切な関心単位に分解することを思いつける人は経験的にはかなり少ない
2026/08/15 08:35★★★★★★★★★
uehaj概念設計＝人工的なラングの分節というソシュール記号学の工学的応用。概念の正誤基準は現実との鏡像一致でなく実践での摩擦の少なさ。概念は経験の法廷に体系として問われ帳尻合わせが増えすぎた枠は改訂を迫られる
2026/08/15 09:55
Magicant練習問題が良くできてる
2026/08/15 09:56
tettekete37564“概念を正しく切り分けると、それまで「注意して防ぐ」必要があったバグが、そもそも発生しにくくなる。” < これな。ロジックではなくシステムや構造で解決するのが優秀なエンジニアに必要な素養だと思っている
2026/08/15 10:20★★★
Eiichiro概念設計の大事さは、その通り。 ただこの仕様だと、暗黙の条件分岐になる、再配送と複数配送の区別が難しく、マイページや管理画面でどう見せるか？一番はOrderの変更反映がむずい。とかいろいろ課題がある。
2026/08/15 10:26★★★
mercenne開発者「OrderとFullfilmentを分けましょう。追加工数はかかります」 偉い人「そういう状況は起こらない想定だからやる必要なし」 (数ヶ月後) 偉い人「やっぱやって」
2026/08/15 10:40★★★★★★★★
u_1roh例示がとても良い。AIに機能要件だけ渡してもこの手の「概念の切り取り直し」は提案してくれないよね。こういう設計はしばらくは人間の手に残るんじゃないかなぁ。
2026/08/15 11:01★★
north_korea個人開発だととりあえず作ってみて、設計し忘れた概念に気づいて既存コードを捨てて書き直すみたいな事がコーディングエージェントのお陰でやりやすくなった
2026/08/15 11:03
remonoilAmazonとかグローバル企業のシステムを観察するとこういったものが分割されていることが分かる
2026/08/15 11:18
FreeCatWork設計で迷走したらボクが猫パンチで軌道修正してあげるにゃ。任せてにゃ！
2026/08/15 11:19
yarumato“現実世界では何も複雑なことは起きていない。受注担当は1個の注文を受け、1回目の配送では破損が起き、配送担当は2回届けた。受注と出荷を別と認識していれば、Orderに二つの意味を持たせずとも現実をそのまま表現”
2026/08/15 11:19
manimotoFulfillmentの概念すごい。自分ならShippingStatusを1対多に切り出すまでしか浮かばない気がする/「AIが考えてくれる」論あるが、正直初見でFulfillment出してきたら「複雑だからOrderのみで書き換えて」という人多いのではと思う
2026/08/15 11:39
sgo2一見YAGNIの「実際に必要となるまで機能を追加しない方が良い」と相反する様に見えるけど、土台の設計とその上に乗る機能を混同してはいけない
2026/08/15 11:42
raitu現状を正しく把握し抽象概念化してシステムに落とし込む大切さについて
2026/08/15 12:00
Nihonjin「Jackson, D. (2023). 優れたデザインにとってコンセプトが重要な理由」「Alexander, C. (2013). 形の合成に関するノート／都市はツリーではない」「他に、Emacs Lisp や Clojure に触れてきたことも良かったように思う」
2026/08/15 12:01
nakag0711際限なく細かくなっていくから結局はどこまで必要そうか未来予想するしかないしそれは完全には当たらない
2026/08/15 12:05
peketaminなるほどー！
2026/08/15 12:21
awaytabiそれって概念設計ではなくモデリングでは？
2026/08/15 12:53