システムとか、Webサービスとか規模が大きくなると、決定的に抽象思考が必要で、中でも高度な「複数層の抽象レベルを扱う能力」が必須なので、具象思考しかできない「プログラマ」が出世してその辺りをいじり出すと、詰む。
マイクロマネジメント的にでかいシステムを扱うから、うまくいくわけがない。
OJTの延長線上に、抽象思考力の育成ってないんよね。
HowToの積み上げしかないから。
なんかわからんけど、これをやれと言われてやってきて、やれてきた。
それの積み上げ。
新しく「××しなけりゃいけない」となったら、今時は便利で、ググったりAI使ったりすれば、HowToが並ぶ。
背後にある体系的な思考法とか、歴史的経緯とか、密接に関係する概念とか、全部すっ飛ばして、HowToだけ集める。
すると、全てがチグハグになる。
一個一個、ミクロに見ると、その場その場はそれっぽく見える。
ちゃんとやれてるように見える。
でも全体を俯瞰すると、背景にあるはずの何層にも渡った網の目のような抽象構造が存在しない。
DDDはこの「何層にも渡った網の目のような抽象構造」のための方法論の一つだって理解しないと、多分正しく適用できない。
画面に対する必要十分な実装とだけ考えると、画面に引っ張られまくる。
が、そこで扱われているデータは、ドメインレベルの抽象度のあるコンセプト(オブジェクト)であり、それにまつわる操作や属性を並べておけば、画面はそれの1断面を切り出しただけ、ってのがわかる。本体のコンセプトがちゃんと捉えられていれば、画面の常識の範囲内での変更は、大した影響はない。せいぜいが属性を増やす(そのあたり、DBの1カラムにしないで、Jsonにぶち込んでおけば、テーブルの変更すら不要な)程度の変動しか起こらない。
そして、それが変更容易性につながっているし、Jsonの1要素が増えるだけなので、処理の根幹は変わってないから、余分なテストは不要、ということだ。
そういう背景とかを知らんでDDD、特にこの「ドメイン」を「業務ドメイン」とか勘違いしているアホウには、到底辿り着けない境地だよね w
と、多分、今の日本のエンジニア業界の致命的な欠陥を指摘してみた。
あー、ちなみに、最近、AI、AIと言われるようになったけど、抽象化しないで具象レベルでAIを投入して多量のソースを生み出したら、まず間違いなく管理不能に陥るからな w
抽象化できない人間が、そんな物量、捌けるわけないから。
システム系で大事な能力は、知識とか経験じゃなく、抽象思考能力だから。