そもそもDDDで表現するドメインってどうやって勉強してるんですかね
掲題の件、多分ビジネス書じゃだめなんですよ。
この手のやつ。
プログラミング自体より、ドメインがどう進化するかで設計迷うわけですよ。脳みそとろける感。
詳しい人に話を聞いたらわかるし出来るレベルじゃないんですよ。現場も実は詳しい人いなくてなんとなくやってるとか、それはやったらあかんことお願いされるとか。例えは、伝票は上書きしたらあかんのやで...月をまたいだ会計と合わんようになるだけちゃうんやで、というのをエンジニアが止めるとか。こんな感じで、エンジニアが、単純に儲かれば何してもいいわけじゃないという文化を作ることを意識して、それをコードに落とすこともあるわけですよ。そういうのって、会計の本読むことも必要なんですけど、それだけじゃないもの求められて脳みそ溶ける感。
あと、中小企業診断士とかリテールマーケティング検定(販売士)とかに関連した本はSKUのSも知らなかった人間なので、ドメインに関する会話でわからなかったことがあったときに、辞書みたいに引いてる。脳みそとろける感。
で、こういう記事もね。実務で異常系対応の地獄とか。
普通にwebサービス作ってきた人と、決済系やってきた人とでは、異常系の想定が違いすぎて、わちゃわちゃするんですよね。信頼でなんとかするものと、事業に必要な安全安心を守るために必要なものとでは違うっていうのをすり合わせるので大変だったり。
人間、激務で疲弊するんじゃなくて、こういう倫理的な対策が現場の俗人的なことに疲弊するんで、信頼も安全安心を守るためには、システム的な対応は必要なんですよ、って話を落とすのに大変なんですよ。システムサイドとしては、人間を危険な場所に置きっぱなしにすると、オペレーションも事業進捗も遅くなるんですよ、事故の処理対応で、って。
ドコモの事件とか他人事じゃないですね。web屋さんと決済やってきた人とではこの辺りのドメインすり合わせる時に、異常系想定増やすと、人信頼してないのかとか、そもそもそういう業務が出るのは何故か、それはシステムの責務じゃなくて窓口の責任、とかに話いきがち。でも、窓口でも止められないという現実の業務に関するすり合わせむずいなーって。窓口守れなくて、窓口を危険にさらしてしまうのはシステムの問題でごめんね、とか。
個人的には、技術単体より、ドメイン自体の学習とすり合わせの方が大変だなって感じがしますね。
