mikekawasaki / iddd-chat-room Goto Github PK
View Code? Open in Web Editor NEWChat app based on DDD & CQRS philosophy and using following technology stacks; SpringBoot/Nuxt/Docker/Terraform(Heroku,AWS)/CircleCI/MySQL/monorepo
Chat app based on DDD & CQRS philosophy and using following technology stacks; SpringBoot/Nuxt/Docker/Terraform(Heroku,AWS)/CircleCI/MySQL/monorepo
core/domain/<aggregate_name>/<aggregate_name>Specification
(core/domain/<aggregate_name>/specification/<usecase_name>Specification)
domain objectに記述できない仕様(repositoryが絡む処理や集約を跨ぐ処理など)を記述する。
各ユースケースを実現する際に必要な使用が一目でわかるようにする。
全メソッドはBoolen型を返し、アプリケーション層でDIして使用する。
(逆にアプリケーション層の責務はエンティティを生成してリポジトリで保存・削除することに集中させる。その際に条件が必要な場合は全てSpecification Classを呼び出すだけにする。)
「ルーム」が作成されてから1時間以上経過していて、最後に送信された「ルーム」内の「メッセージ」が1時間以上前のものであれば、どの「ルーム」でも削除することができる。
↓
Specificationクラスを採用するのはEntityで工夫してうまくいかなかった場合の最終手段。
ルームを削除するには、
この条件はルームの集約ルートで判断する。
isCreatedBy
メソッド
repository使う。
specificationクラスでhasMessageメソッドで定義。
この条件はルームの集約ルートで判断する。
meetsCreatedDateTimeRequirementToDelete
メソッド
ルーム内に最後に送信されたメッセージを取得するには、repositoryを使用するため、この取得処理はアプリケーション層(specificationクラス)で行う。
この条件はメッセージの集約ルートで判断する。
meetsSentDateTimeRequirementToDeleteRoom
メソッド
ルーム自体がメッセージを持つ必要はないのでは?
→メッセージがルームIDを持てばいい。
返信したメッセージIDがわかればスレッド内のメッセージをリストとして保存しなくても良い。
ドメインレベルで普通のメッセージとリプライメッセージを区別するのではなく、アプリケーションレベルで利用時に区別するようにした。
→今後の考え方として、リスト形式で膨大な数のエンティティを持つような構成になったら疑った方がいいかも。
単純に足りてなかったので追加。
送信日時は、DB側のcreated_atをアプリケーションで使うのはDBと密結合になってよろしくないと思ったのでVOを追加してアプリケーション側で早期生成した値を使うようにした。
ただ、DB側にもレコード管理としてcreated_atカラムは作成する予定。つまりレコードはエンティティの生成日時とレコードの作成日時を同時に管理する状態。この判断はどうなのか?
単純に足りてなかったので追加。
作成日時については同上。
テキスト(1-1000文字必須入力)+任意で画像(1枚まで)
という仕様に変更した。
どのメッセージに対しても合計1000件までメッセージ返信をすることできる。
↓
どのメッセージに対しても合計5件までメッセージ返信をすることできる。
(1000件だと再現性がないため、5件として実際アプリケーション上で仕様が反映されていることを確認できるようにした)
スレッド内のメッセージ数(上記を満たすだけなら厳密にはメッセージ数を持つ必要はない。返信できるかどうかのステータス)をメッセージに持たせたい。
→実現するにはメッセージの送信を監視するようなイベント駆動的な形にする必要がある。
↓
とりあえずいったん無視。細かいところが形ができたら修正。
必要になったタイミングでfile集約を追加
必要になったタイミングでauthentication集約を追加
varchar型は文字コードがutf8mb4は最大文字数が191。
text型は文字数制限できないはず。
とりあえずtext型にして、DB格納前にバリデーションかければいい?
(データベース側で100%保証できないのが不安だが、フロント・バックエンドでにリクエスト時のバリデーションとVOでそれぞれバリデーションをかければシステム的には変な値は入らないと言えるはず。)
→UserAccount Aggregateに権限用のVOを追加。
これを用いてルーム作成のapplicationServiceをAOPで管理する。
将来の変更可能性を考えたときに、生のメッセージと返信は仕様が大きく異なる可能性があるため。
coming soon...
将来の変更性を見据えて。
現時点でメッセージとリプライは仕様が多少異なっている。(リプライにリプライはできない点)
この仕様のズレはサービスの拡張ととともに大きくなっていく可能性が高い。
したがって、現時点で仕様が異なっているのであれば、将来の変更可能性を見据えて分割するのが自然と判断した。
共通部分は抽象クラスBaseMassageクラスで定義して継承する。
単純に忘れていたため。
ルーム内にあるメッセージはルームが削除後は不要とし物理削除する。
とりあえずアプリケーション層で例外出すようにしている。ユーザーにロール持たせて管理したい。
「参加者」同士が「ルーム」内で「メッセージ」のやりとりができるSPA。
本サービスを利用するアクター(人物)。
参加者がサービスを利用するためのアカウント。名前とアイコンが設定できる。(ただし、メールアドレスやパスワードはない。)
参加者が「メッセージ」のやりとりができる場所。
「ルーム」を閲覧できる参加者の閾値(メッセージ送信回数)を示すもの。
例えば、「ルーム」の「ルームレベル」が10の場合、その「ルーム」の内容は10回以上「メッセージ」を送信した参加者のみが閲覧でき、「メッセージ」を送信できる。
参加者が「ルーム」に対して送信するもの。形式にはテキストと画像がある。
ある「メッセージ」に対して別のメッセージを返信できる場所、またそのメッセージのまとまり。
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.