DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
開発チーム間の情報を遠回りさせてる - Mitsuyuki.Shiiba
いまの会社では、エンジニアどうしの距離が近いので、他のチームのエンジニアと一緒に開発に取り組んでたりする。 のだけど僕からは 「この部分はディレクター（社内でスクラムマスター的なロール）さんから、あのチームのディレクターさんに共有してもらってもいいですか？」 って自分のチームのディレクターにお願いしたり 「この部分はプロダクトマネージャ（社内のプロダクトオーナー的なロール）さんから、他のチームに確認してもらってもいいですか？」 ってプロダクトマネージャにお願いしたりしてる。エンジニアどうしで話をして、お互いに状況を理解しているのに、公式なルートとしては、情報を遠回りさせているのだ。 そんなお願いをすると、一瞬（え？エンジニアどうしで話して認識合ってるのに？）って反応をされるし、僕自身も（大企業っぽいかなぁ？）って思ったりするのだけど、自分の気持ちを説明すると「たしかにそうね。おっけー！やっ
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
