アプリ開発日記　#162 引き続きテーブル周りの実装

新しく作るアプリ

いつも期限前日に焦ってしまう人のためのスケジュール管理アプリを作ろうと考えています。

今日の作業

テーブル周りの実装をさらに進めました。
単純な検索や登録の機能だけでなく、複雑なSQLによるデータの取得処理を実装しました。

実装していて感じたことは、これSQLじゃなくてドメインサービスとかでやったほうがよくね?ということでした。
というのもSQLを使用した存在確認などをしたのですが、SQL自体が複雑になってしまい、修正が難しい機能となってしまったためです。
そして、ドメインの知識がDB側に漏れてしまっているため、設計としてはあまりよくないように思いました。

ただ、プログラム側でループと化してデータの確認をするより、DBで対応したほうがパフォーマンスがよかったりするので、その辺はケースバイケースでもいいのかなと思っています。

あと、過去に作ったiOS版のアプリについて、証明書を更新して審査に出しています。
この作業に機能半日くらいかかってしまいました。
お疲れさまでした。

明日以降の作業

テーブル周りの実装を続ける
UnitTestを組む

今後の課題

<<大量の設計書がなくても、過不足なく使用を説明できるようにしたい>>

アプリが複雑になると設計書の量が増えてしまいます。
しかし、すべての設計書の整合性を取りながら、アプリを修正することは結構大変だと思います。

今回も、複数の設計書の間で不整合が起きていたことで、バグを作りこむところでした。

そのため、仕様を説明するためのドキュメントについて、もっといい感じでまとめられるようにしたいです。<>
アプリケーションサービスや、ドメインモデル、ドメインサービスのそれぞれの役割を明確に定義できていなかった、そして十分に理解できていなかったため、実装時に実装するレイヤーが違うものがいくつか表れてしまいました。

そのため、改めてアプリケーションサービスや、ドメインモデル、ドメインサービスのそれぞれの役割を明確に定義できるようにしたいと思います。