TOC
3月の振り返り
Reactの開発案件はサーバ側の対応待ち。当分リリースできなそうなのでTry for next monthに移動する。 Reactの文字列加工システム（上記とは別のシステム）を開発中。Reactに慣れてきたが、設計がうまくできていない気がしている。NoSQLのデータベース設計ももやもやしながら進めている。DB設計事例を見ながら見様見真似で実験中。リリースした後にDB修正しにくそうなのでなかなかリリースに踏み込めない。 DDD周りの学習は平日の常駐先で積むことができている。
私生活に新型コロナの影響が大きく出ている。 1月末から平日の仕事はリモートに変わり、通勤時間が減った分を運動と勉強時間に費やしている。 ドラゴン桜や小学館の少年少女日本の歴史が無料公開されていたり、株の大幅下落を受けて投資に費やす時間に多くを費やしてしまった。（後悔はしていない）
Achieved
開発
SQLアンチパターンを読む → 40%読了 「実践ドメイン駆動設計」から学ぶDDDの実装入門 ⇒ 読了 DDD案件の経験（@開発現場）
DDD開発現場のぼやき
開発現場で感じたことだが、大規模な業務アプリケーションの場合、設計書を完全に廃止することは難しい現場が多いと思う。私が今参画している現場も同様で、設計チームが設計書を作成し、開発チームが設計書を元にDDDの開発を行っている。 設計チームと開発チームの意識の違いがあり、どうしても設計書はDDDに則しておらず（そりゃ設計チームメンバーがDDDに熟知していたりDDDを意識した設計をするのは無茶だと思うけど）、設計書と実装に差が出てしまう。 設計書を見て実装を見て、どこがどこと紐づいているかがわかりにくく、結局実装を詳細に見て仕様を理解しなければならない。少量なら簡単だが、設計書が10個、実装箇所が10クラスを超えるとかなりしんどい。 実装箇所を見て内部的に何をやっているか自信を持って推測できたりすれば良いんだけど、規模が大きくなってくるとなかなかクラス名・メソッド名だけから自信を持って判断ができず。。 lambdaの受け渡しが多かったりするので責務を絞る必要があるのではないか、DDDで言うコアドメインの線引きがうまくできていないのではともやもやしながら開発しています。（じゃあどうすれば良いのか、が浮かばないのが悔しい！！）
フロントエンド
React-Reduxシステムを構築中 FirebaseAuthenticationを使った認証機能を実装 CloudFirestoreの設計例をいくつか探して冗長な構成で実装。パフォーマンスは後回し CloudFunctionsによりFirestoreのデータコピー等を実装
基礎
法律を読む技術・学ぶ技術［改訂第３版］ → 読了（ITではないけど教養として学習）
Problem
新規
なし
継続中・保留
ビルド・デプロイツールの知識が少ない → React案件で多少解決予定 アーキテクト経験がない（1からシステム構成を検討） → React案件で解決予定 AtCorderで有向グラフが理解できていない AtCorderでDPのパターン経験が不足
解消
なし
Try for next month
3月はFirebaseを用いたReactベースのシステム構築がメイン。 書面学習ばかりであったため3月からは手を動かす時間を長くしたい。当面コロナウイルス影響により資格試験も受けたくない（密室空間に居たくない）ので丁度良い。 React-Redux回りで良い設計ができているのか評価できない。時間ができたら他人の設計を見てみたい。
新規
ドメイン駆動設計入門を読む
継続中（前月中に達成できなかった）
Firebase上で文字列加工システムを公開する。 複雑な宿予約システムのDDD開発練習 モデリングスキルを高める書籍を読む Reactの開発案件はサーバ側の対応待ち
Done
DDD書籍（IDDDを読み解く本）を読む
