以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。
TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。
じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。
トランザクション境界
トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。
だから、トランザクション境界を作ってDBを小さく保てば、そこに対するサービス（アプリケーション）も小さく保てるかなと。サービスが小さければその中でSQLの力を活かした素朴なコードを書いても、そこまで複雑にはならないんじゃないかなという気持ち。
トランザクション境界があると、それを超えた整合性の伝搬には非同期処理を使う必要があるなど、別の複雑さを持ち込んでしまうけど、DBが一手に担ってくれてた複雑さをどう分散させるか、そのあたりをうまくやることに今は興味がある。
ユビキタス言語
ユビキタス言語は、とても意識している。PdMが喋る言葉から、ドキュメントはもちろん、プログラムの中まで同じ言葉を使うようにしている。
たとえば「薬品」はプログラムの中でもそのまま「Yakuhin」となっている。バックエンドで変数名などに漢字を使うのは予期せぬ問題にぶつかりそうだから、ローマ字にしてる。ちなみに、フロントエンドでは日本語コンポーネントを使ってる。ぱっと見て理解できる漢字のすばらしさよ。
ある日PdMが「医薬品がどうこう」と言って、エンジニアが「お？」ってなって「薬品と医薬品は使い分けています？」「あぁ、そう言われてみればそうですね！」みたいな話をして、僕らの中では「薬品」と「医薬品」が別のものとして認識された。もし「薬品」がコードの中で「Medicine」と書かれていたら、エンジニアは医薬品と薬品の違いに気づかなかったと思う。
認識の違いを拾いたいので、会話からコードまで同じ言葉を使うようにしている。そんな風に、ユビキタス言語はとても意識している。
小さく保つ、名前にこだわる、それで複雑さに立ち向かう
という感じで、今は、影響範囲を小さく保つことと、名前にこだわることに興味を持っている。いちどに気にする範囲を小さく保って、レイヤーを分けて、意識しておくべきロジックは凝集させて、変数や関数やモジュールの名前にこだわる。1つの関数をできるだけ小さくする。依存の向きは一方向にする。イミュータブルにする。
なんかそんな普通のことを考えている。DDDでドメインの複雑さに立ち向かうことに興味があって、実装の方は別にいい感じでいいかなという気持ちになっている。
来年にはまた実装が気になってるかもしれないけどー。今はそんな気持ち。
