まず最初に前回のおさらいとして前回の実装の一部を再掲します。<pre><code>// サービス層
class MeetingService(
 meetingRepository: MeetingRepository,
 userRepsitory: UserRepository
):
 def reserve(
 organizerId: UserId,
 participantIds: List[UserId],
 startAt: LocalDateTime,
 endAt: LocalDateTime,
 title: String,
 detail: String
 ): Unit =
 val meeting =
 Meeting(organizerId, participantIds, startAt, endAt, title, detail)
 meetingRepository.save(meeting)

 def notify(user: User) =
 EmailSender().send(user.email, title, detail)
 EmailReserver().reserve(user.email, title, detail, startAt)
 EmailReserver().reserve(user.email, title, detail, endAt)

 val users = userRepsitory.getByIds(organizerId :: participantIds)
 users.foreach(notify)</code></pre> 現時点では特に問題のあるコードのようには思えません。では、（少々こじつけ感がありますが）以下のような仕様を追加します。<ul><li>このシステムには別のユーザをフォローする機能も他にある</li><li>主催者は参加者を選んでミーティングを作成することの他に、参加者を自分で直接選ばずミーティングを作成することもできる<ul><li>その場合、参加者は自分をフォローしているユーザに設定される</li></ul></li></ul> 雑に実装するとこんな感じでしょうか。<pre><code>-class User(val id: UserId, val email: Email)
+class User(val id: UserId, val email: Email):
+&nbsp; def followed: List[User] =
+&nbsp; &nbsp; List(
+&nbsp; &nbsp; &nbsp; User(UserId(1), Email("hoge1@example.com")),
+&nbsp; &nbsp; &nbsp; User(UserId(2), Email("hoge2@example.com"))
+&nbsp; &nbsp; )
&nbsp;
&nbsp;trait UserRepository:
+&nbsp; def get(id: UserId) =
+&nbsp; &nbsp; User(id, Email("hoge@example.com"))
+
&nbsp; &nbsp;def getByIds(ids: List[UserId]) =
&nbsp; &nbsp; &nbsp;ids.map(User(_, Email("hoge@example.com")))
&nbsp;
@@ -97,3 +105,24 @@ class MeetingService(
&nbsp;
&nbsp; &nbsp; &nbsp;val users = userRepsitory.getByIds(organizerId :: participantIds)
&nbsp; &nbsp; &nbsp;users.foreach(notify)
+
+&nbsp; def reserveWithFollowed(
+&nbsp; &nbsp; &nbsp; organizerId: UserId,
+&nbsp; &nbsp; &nbsp; startAt: LocalDateTime,
+&nbsp; &nbsp; &nbsp; endAt: LocalDateTime,
+&nbsp; &nbsp; &nbsp; title: String,
+&nbsp; &nbsp; &nbsp; detail: String
+&nbsp; ): Unit =
+&nbsp; &nbsp; val organizer = userRepsitory.get(organizerId)
+&nbsp; &nbsp; val followers = organizer.followed
+&nbsp; &nbsp; val meeting =
+&nbsp; &nbsp; &nbsp; Meeting(organizerId, followers.map(_.id), startAt, endAt, title, detail)
+&nbsp; &nbsp; meetingRepository.save(meeting)
+
+&nbsp; &nbsp; def notify(user: User) =
+&nbsp; &nbsp; &nbsp; EmailSender().send(user.email, title, detail)
+&nbsp; &nbsp; &nbsp; EmailReserver().reserve(user.email, title, detail, startAt)
+&nbsp; &nbsp; &nbsp; EmailReserver().reserve(user.email, title, detail, endAt)
+
+&nbsp; &nbsp; val users = userRepsitory.getByIds(organizerId :: followers.map(_.id))
+&nbsp; &nbsp; users.foreach(notify)</code></pre> こうなってくると、流石にリファクタしたくなってきます。とりあえず一旦通知関連の処理を内部メソッドに切り出しましょう。<pre><code>@@ -98,13 +98,14 @@ class MeetingService(
&nbsp; &nbsp; &nbsp; &nbsp;Meeting(organizerId, participantIds, startAt, endAt, title, detail)
&nbsp; &nbsp; &nbsp;meetingRepository.save(meeting)
&nbsp;
-&nbsp; &nbsp; def notify(user: User) =
-&nbsp; &nbsp; &nbsp; EmailSender().send(user.email, title, detail)
-&nbsp; &nbsp; &nbsp; EmailReserver().reserve(user.email, title, detail, startAt)
-&nbsp; &nbsp; &nbsp; EmailReserver().reserve(user.email, title, detail, endAt)
-
-&nbsp; &nbsp; val users = userRepsitory.getByIds(organizerId :: participantIds)
-&nbsp; &nbsp; users.foreach(notify)
+&nbsp; &nbsp; notifyMeetingCreated(
+&nbsp; &nbsp; &nbsp; organizerId,
+&nbsp; &nbsp; &nbsp; participantIds,
+&nbsp; &nbsp; &nbsp; title,
+&nbsp; &nbsp; &nbsp; detail,
+&nbsp; &nbsp; &nbsp; startAt,
+&nbsp; &nbsp; &nbsp; endAt
+&nbsp; &nbsp; )
&nbsp;
&nbsp; &nbsp;def reserveWithFollowed(
&nbsp; &nbsp; &nbsp; &nbsp;organizerId: UserId,
@@ -119,10 +120,27 @@ class MeetingService(
&nbsp; &nbsp; &nbsp; &nbsp;Meeting(organizerId, followers.map(_.id), startAt, endAt, title, detail)
&nbsp; &nbsp; &nbsp;meetingRepository.save(meeting)
&nbsp;
+&nbsp; &nbsp; notifyMeetingCreated(
+&nbsp; &nbsp; &nbsp; organizerId,
+&nbsp; &nbsp; &nbsp; followers.map(_.id),
+&nbsp; &nbsp; &nbsp; title,
+&nbsp; &nbsp; &nbsp; detail,
+&nbsp; &nbsp; &nbsp; startAt,
+&nbsp; &nbsp; &nbsp; endAt
+&nbsp; &nbsp; )
+
+&nbsp; private def notifyMeetingCreated(
+&nbsp; &nbsp; &nbsp; organizerId: UserId,
+&nbsp; &nbsp; &nbsp; participantIds: List[UserId],
+&nbsp; &nbsp; &nbsp; title: String,
+&nbsp; &nbsp; &nbsp; detail: String,
+&nbsp; &nbsp; &nbsp; startAt: LocalDateTime,
+&nbsp; &nbsp; &nbsp; endAt: LocalDateTime
+&nbsp; ): Unit =
&nbsp; &nbsp; &nbsp;def notify(user: User) =
&nbsp; &nbsp; &nbsp; &nbsp;EmailSender().send(user.email, title, detail)
&nbsp; &nbsp; &nbsp; &nbsp;EmailReserver().reserve(user.email, title, detail, startAt)
&nbsp; &nbsp; &nbsp; &nbsp;EmailReserver().reserve(user.email, title, detail, endAt)
&nbsp;
-&nbsp; &nbsp; val users = userRepsitory.getByIds(organizerId :: followers.map(_.id))
+&nbsp; &nbsp; val users = userRepsitory.getByIds(organizerId :: participantIds)
&nbsp; &nbsp; &nbsp;users.foreach(notify)</code></pre> 多少はスッキリしました。内部メソッドが大量の引数を受け取っているのが気持ち悪いですが、一旦目を瞑ります。

複数箇所で発生するイベント

更に要件が追加され、ミーティング情報を削除した際にも主催者と参加者全員に対してメール通知をすることになったとします。実装してみます。<pre><code>@@ -55,17 +55,22 @@ trait UserRepository:
&nbsp; &nbsp;def getByIds(ids: List[UserId]) =
&nbsp; &nbsp; &nbsp;ids.map(User(_, Email("hoge@example.com")))
&nbsp;
+class MeetingId(val value: Int) extends AnyVal
+
&nbsp;class Meeting(
-&nbsp; &nbsp; organizerId: UserId,
-&nbsp; &nbsp; participantIds: List[UserId],
-&nbsp; &nbsp; startAt: LocalDateTime,
-&nbsp; &nbsp; endAt: LocalDateTime,
-&nbsp; &nbsp; title: String,
-&nbsp; &nbsp; detail: String
+&nbsp; &nbsp; val id: Option[MeetingId],
+&nbsp; &nbsp; val organizerId: UserId,
+&nbsp; &nbsp; val participantIds: List[UserId],
+&nbsp; &nbsp; val startAt: LocalDateTime,
+&nbsp; &nbsp; val endAt: LocalDateTime,
+&nbsp; &nbsp; val title: String,
+&nbsp; &nbsp; val detail: String
&nbsp;)
&nbsp;
&nbsp;trait MeetingRepository:
&nbsp; &nbsp;def save(meeting: Meeting): Unit
+&nbsp; def get(meetingId: MeetingId): Meeting
+&nbsp; def delete(meetingId: MeetingId): Unit
&nbsp;
&nbsp;// インフラストラクチャ層
&nbsp;class EmailSender:
@@ -95,7 +100,7 @@ class MeetingService(
&nbsp; &nbsp; &nbsp; &nbsp;detail: String
&nbsp; &nbsp;): Unit =
&nbsp; &nbsp; &nbsp;val meeting =
-&nbsp; &nbsp; &nbsp; Meeting(organizerId, participantIds, startAt, endAt, title, detail)
+&nbsp; &nbsp; &nbsp; Meeting(None, organizerId, participantIds, startAt, endAt, title, detail)
&nbsp; &nbsp; &nbsp;meetingRepository.save(meeting)
&nbsp;
&nbsp; &nbsp; &nbsp;notifyMeetingCreated(
@@ -117,7 +122,15 @@ class MeetingService(
&nbsp; &nbsp; &nbsp;val organizer = userRepsitory.get(organizerId)
&nbsp; &nbsp; &nbsp;val followers = organizer.followed
&nbsp; &nbsp; &nbsp;val meeting =
-&nbsp; &nbsp; &nbsp; Meeting(organizerId, followers.map(_.id), startAt, endAt, title, detail)
+&nbsp; &nbsp; &nbsp; Meeting(
+&nbsp; &nbsp; &nbsp; &nbsp; None,
+&nbsp; &nbsp; &nbsp; &nbsp; organizerId,
+&nbsp; &nbsp; &nbsp; &nbsp; followers.map(_.id),
+&nbsp; &nbsp; &nbsp; &nbsp; startAt,
+&nbsp; &nbsp; &nbsp; &nbsp; endAt,
+&nbsp; &nbsp; &nbsp; &nbsp; title,
+&nbsp; &nbsp; &nbsp; &nbsp; detail
+&nbsp; &nbsp; &nbsp; )
&nbsp; &nbsp; &nbsp;meetingRepository.save(meeting)
&nbsp;
&nbsp; &nbsp; &nbsp;notifyMeetingCreated(
@@ -144,3 +157,14 @@ class MeetingService(
&nbsp;
&nbsp; &nbsp; &nbsp;val users = userRepsitory.getByIds(organizerId :: participantIds)
&nbsp; &nbsp; &nbsp;users.foreach(notify)
+
+&nbsp; def remove(meetingId: MeetingId): Unit =
+&nbsp; &nbsp; val meeting = meetingRepository.get(meetingId)
+&nbsp; &nbsp; meetingRepository.delete(meetingId)
+
+&nbsp; &nbsp; def notify(user: User) =
+&nbsp; &nbsp; &nbsp; EmailSender().send(user.email, "ミーティング削除のお知らせ", "ミーティングが削除されました")
+
+&nbsp; &nbsp; val userIds = meeting.organizerId :: meeting.participantIds
+&nbsp; &nbsp; val users = userRepsitory.getByIds(userIds)
+&nbsp; &nbsp; users.foreach(notify)</code></pre> また個別の通知ロジックが出てきました。今回はコードの重複を予想し、先に内部メソッドに切り出しておきましょう。<pre><code>@@ -162,9 +162,15 @@ class MeetingService(
&nbsp; &nbsp; &nbsp;val meeting = meetingRepository.get(meetingId)
&nbsp; &nbsp; &nbsp;meetingRepository.delete(meetingId)
&nbsp;
+&nbsp; &nbsp; notifyMeetingDeleted(meeting.organizerId, meeting.participantIds)
+
+&nbsp; private def notifyMeetingDeleted(
+&nbsp; &nbsp; &nbsp; organizerId: UserId,
+&nbsp; &nbsp; &nbsp; participantIds: List[UserId]
+&nbsp; ): Unit =
&nbsp; &nbsp; &nbsp;def notify(user: User) =
&nbsp; &nbsp; &nbsp; &nbsp;EmailSender().send(user.email, "ミーティング削除のお知らせ", "ミーティングが削除されました")
&nbsp;
-&nbsp; &nbsp; val userIds = meeting.organizerId :: meeting.participantIds
+&nbsp; &nbsp; val userIds = organizerId :: participantIds
&nbsp; &nbsp; &nbsp;val users = userRepsitory.getByIds(userIds)
&nbsp; &nbsp; &nbsp;users.foreach(notify)</code></pre>

別のイベント

現状の実装の何が問題でしょうか。例えば、以下のような仕様変更があったとします。<ul><li>メール通知の他にプッシュ通知も追加してほしい</li><li>メール通知の際にHTMLかプレーンテキストかを選択できるようにしたい</li></ul>いずれの場合も複数箇所を修正する必要があります。今はミーティングサービスだけしか見ていませんが、他のサービスを考えると更に多くの箇所を修正しなくてはなりません。影響範囲の特定・修正に時間がかかりますし、リグレッションにも注意しなければなりません。 行き当りばったりのリファクタではなく、根本的な設計を考え直してみます。<ul><li>「ミーティングが作成された」「ミーティングが削除された」のような「イベント」が存在する</li><li>メール送信者、メール予約者など、イベントの「観測者」が存在する</li><li>イベントは任意の場所から発行される。観測者はイベントが発行されるとそのイベントの種類に応じて反応する</li></ul>この設計でリファクタし直してみましょう。

問題点と対応方針

<pre><code>@@ -58,26 +58,65 @@ trait UserRepository:
&nbsp;class MeetingId(val value: Int) extends AnyVal
&nbsp;
&nbsp;class Meeting(
-&nbsp; &nbsp; val id: Option[MeetingId],
&nbsp; &nbsp; &nbsp;val organizerId: UserId,
&nbsp; &nbsp; &nbsp;val participantIds: List[UserId],
&nbsp; &nbsp; &nbsp;val startAt: LocalDateTime,
&nbsp; &nbsp; &nbsp;val endAt: LocalDateTime,
&nbsp; &nbsp; &nbsp;val title: String,
&nbsp; &nbsp; &nbsp;val detail: String
-)
+):
+&nbsp; val id = MeetingId(1)
&nbsp;
&nbsp;trait MeetingRepository:
&nbsp; &nbsp;def save(meeting: Meeting): Unit
&nbsp; &nbsp;def get(meetingId: MeetingId): Meeting
&nbsp; &nbsp;def delete(meetingId: MeetingId): Unit
&nbsp;
+trait DomainEvent:
+&nbsp; val occuredOn = LocalDateTime.now()
+
+class MeetingCreated(
+&nbsp; &nbsp; val meetingId: MeetingId,
+&nbsp; &nbsp; val users: List[User],
+&nbsp; &nbsp; val title: String,
+&nbsp; &nbsp; val detail: String,
+&nbsp; &nbsp; val startAt: LocalDateTime,
+&nbsp; &nbsp; val endAt: LocalDateTime
+) extends DomainEvent
+
+class MeetingDeleted(
+&nbsp; &nbsp; val meetingId: MeetingId,
+&nbsp; &nbsp; val users: List[User]
+) extends DomainEvent
+
+trait DomainEventObserver:
+&nbsp; def respondTo[T &lt;: DomainEvent](event: T): Unit
+
+class DomainEventPublisher(obs: DomainEventObserver*):
+&nbsp; def publish[T &lt;: DomainEvent](event: T): Unit =
+&nbsp; &nbsp; obs.foreach(_.respondTo(event))
+
&nbsp;// インフラストラクチャ層
-class EmailSender:
+class EmailSender extends DomainEventObserver:
+&nbsp; override def respondTo[T &lt;: DomainEvent](event: T): Unit =
+&nbsp; &nbsp; event match
+&nbsp; &nbsp; &nbsp; case e: MeetingCreated =&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; e.users.foreach(u =&gt; send(u.email, e.title, e.detail))
+&nbsp; &nbsp; &nbsp; case e: MeetingDeleted =&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; e.users.foreach(u =&gt; send(u.email, "ミーティング削除のお知らせ", "ミーティングが削除されました"))
+
&nbsp; &nbsp;def send(to: Email, subject: String, body: String): Unit =
&nbsp; &nbsp; &nbsp;println(s"email send to $to")
&nbsp;
-class EmailReserver:
+class EmailReserver extends DomainEventObserver:
+&nbsp; override def respondTo[T &lt;: DomainEvent](event: T): Unit =
+&nbsp; &nbsp; event match
+&nbsp; &nbsp; &nbsp; case e: MeetingCreated =&gt;
+&nbsp; &nbsp; &nbsp; &nbsp; e.users.foreach(u =&gt; {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; reserve(u.email, e.title, e.detail, e.startAt)
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; reserve(u.email, e.title, e.detail, e.endAt)
+&nbsp; &nbsp; &nbsp; &nbsp; })
+
&nbsp; &nbsp;def reserve(
&nbsp; &nbsp; &nbsp; &nbsp;to: Email,
&nbsp; &nbsp; &nbsp; &nbsp;subject: String,
@@ -91,6 +130,8 @@ class MeetingService(
&nbsp; &nbsp; &nbsp;meetingRepository: MeetingRepository,
&nbsp; &nbsp; &nbsp;userRepsitory: UserRepository
&nbsp;):
+&nbsp; private val publisher = DomainEventPublisher(EmailSender(), EmailReserver())
+
&nbsp; &nbsp;def reserve(
&nbsp; &nbsp; &nbsp; &nbsp;organizerId: UserId,
&nbsp; &nbsp; &nbsp; &nbsp;participantIds: List[UserId],
@@ -100,16 +141,18 @@ class MeetingService(
&nbsp; &nbsp; &nbsp; &nbsp;detail: String
&nbsp; &nbsp;): Unit =
&nbsp; &nbsp; &nbsp;val meeting =
-&nbsp; &nbsp; &nbsp; Meeting(None, organizerId, participantIds, startAt, endAt, title, detail)
+&nbsp; &nbsp; &nbsp; Meeting(
+&nbsp; &nbsp; &nbsp; &nbsp; organizerId,
+&nbsp; &nbsp; &nbsp; &nbsp; participantIds,
+&nbsp; &nbsp; &nbsp; &nbsp; startAt,
+&nbsp; &nbsp; &nbsp; &nbsp; endAt,
+&nbsp; &nbsp; &nbsp; &nbsp; title,
+&nbsp; &nbsp; &nbsp; &nbsp; detail
+&nbsp; &nbsp; &nbsp; )
&nbsp; &nbsp; &nbsp;meetingRepository.save(meeting)
-
-&nbsp; &nbsp; notifyMeetingCreated(
-&nbsp; &nbsp; &nbsp; organizerId,
-&nbsp; &nbsp; &nbsp; participantIds,
-&nbsp; &nbsp; &nbsp; title,
-&nbsp; &nbsp; &nbsp; detail,
-&nbsp; &nbsp; &nbsp; startAt,
-&nbsp; &nbsp; &nbsp; endAt
+&nbsp; &nbsp; val users = userRepsitory.getByIds(organizerId :: participantIds)
+&nbsp; &nbsp; publisher.publish(
+&nbsp; &nbsp; &nbsp; MeetingCreated(meeting.id, users, title, detail, startAt, endAt)
&nbsp; &nbsp; &nbsp;)
&nbsp;
&nbsp; &nbsp;def reserveWithFollowed(
@@ -123,7 +166,6 @@ class MeetingService(
&nbsp; &nbsp; &nbsp;val followers = organizer.followed
&nbsp; &nbsp; &nbsp;val meeting =
&nbsp; &nbsp; &nbsp; &nbsp;Meeting(
-&nbsp; &nbsp; &nbsp; &nbsp; None,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;organizerId,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;followers.map(_.id),
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;startAt,
@@ -132,45 +174,14 @@ class MeetingService(
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;detail
&nbsp; &nbsp; &nbsp; &nbsp;)
&nbsp; &nbsp; &nbsp;meetingRepository.save(meeting)
-
-&nbsp; &nbsp; notifyMeetingCreated(
-&nbsp; &nbsp; &nbsp; organizerId,
-&nbsp; &nbsp; &nbsp; followers.map(_.id),
-&nbsp; &nbsp; &nbsp; title,
-&nbsp; &nbsp; &nbsp; detail,
-&nbsp; &nbsp; &nbsp; startAt,
-&nbsp; &nbsp; &nbsp; endAt
+&nbsp; &nbsp; val users = userRepsitory.getByIds(organizerId :: followers.map(_.id))
+&nbsp; &nbsp; publisher.publish(
+&nbsp; &nbsp; &nbsp; MeetingCreated(meeting.id, users, title, detail, startAt, endAt)
&nbsp; &nbsp; &nbsp;)
&nbsp;
-&nbsp; private def notifyMeetingCreated(
-&nbsp; &nbsp; &nbsp; organizerId: UserId,
-&nbsp; &nbsp; &nbsp; participantIds: List[UserId],
-&nbsp; &nbsp; &nbsp; title: String,
-&nbsp; &nbsp; &nbsp; detail: String,
-&nbsp; &nbsp; &nbsp; startAt: LocalDateTime,
-&nbsp; &nbsp; &nbsp; endAt: LocalDateTime
-&nbsp; ): Unit =
-&nbsp; &nbsp; def notify(user: User) =
-&nbsp; &nbsp; &nbsp; EmailSender().send(user.email, title, detail)
-&nbsp; &nbsp; &nbsp; EmailReserver().reserve(user.email, title, detail, startAt)
-&nbsp; &nbsp; &nbsp; EmailReserver().reserve(user.email, title, detail, endAt)
-
-&nbsp; &nbsp; val users = userRepsitory.getByIds(organizerId :: participantIds)
-&nbsp; &nbsp; users.foreach(notify)
-
&nbsp; &nbsp;def remove(meetingId: MeetingId): Unit =
&nbsp; &nbsp; &nbsp;val meeting = meetingRepository.get(meetingId)
&nbsp; &nbsp; &nbsp;meetingRepository.delete(meetingId)
-
-&nbsp; &nbsp; notifyMeetingDeleted(meeting.organizerId, meeting.participantIds)
-
-&nbsp; private def notifyMeetingDeleted(
-&nbsp; &nbsp; &nbsp; organizerId: UserId,
-&nbsp; &nbsp; &nbsp; participantIds: List[UserId]
-&nbsp; ): Unit =
-&nbsp; &nbsp; def notify(user: User) =
-&nbsp; &nbsp; &nbsp; EmailSender().send(user.email, "ミーティング削除のお知らせ", "ミーティングが削除されました")
-
-&nbsp; &nbsp; val userIds = organizerId :: participantIds
-&nbsp; &nbsp; val users = userRepsitory.getByIds(userIds)
-&nbsp; &nbsp; users.foreach(notify)
+&nbsp; &nbsp; val users =
+&nbsp; &nbsp; &nbsp; userRepsitory.getByIds(meeting.organizerId :: meeting.participantIds)
+&nbsp; &nbsp; publisher.publish(MeetingDeleted(meeting.id, users))</code></pre> アプリケーションサービスの実装がすっきりし、通知に関するロジックはそれぞれの観測者のイベントごとの実装に収まりました。（なお、実装はデザインパターンのObserverパターンを使用しているつもりです。）まだまだ改善の余地はありそうですが、長くなってきたので今回はここまでとします。 そういえば、ようやく出てきましたね、<pre><code>+&nbsp; def respondTo[T &lt;: DomainEvent](event: T): Unit</code></pre> 上限境界です。Pub/Subの実装に気を取られてこのブログの趣旨を忘れてしまっていました(笑)

リファクタリング

今回は、イベントの発火に関するロジックをまとめるために、Observerパターンを使用してリファクタしました。現時点でのコードの全容を貼っておきます。<pre><code>// ドメイン層
class UserId(val value: Int) extends AnyVal
class Email(val value: String) extends AnyVal

class User(val id: UserId, val email: Email):
 def followed: List[User] =
 List(
 User(UserId(1), Email("hoge1@example.com")),
 User(UserId(2), Email("hoge2@example.com"))
 )

trait UserRepository:
 def get(id: UserId) =
 User(id, Email("hoge@example.com"))

 def getByIds(ids: List[UserId]) =
 ids.map(User(_, Email("hoge@example.com")))

class MeetingId(val value: Int) extends AnyVal

class Meeting(
 val organizerId: UserId,
 val participantIds: List[UserId],
 val startAt: LocalDateTime,
 val endAt: LocalDateTime,
 val title: String,
 val detail: String
):
 val id = MeetingId(1)

trait MeetingRepository:
 def save(meeting: Meeting): Unit
 def get(meetingId: MeetingId): Meeting
 def delete(meetingId: MeetingId): Unit

trait DomainEvent:
 val occuredOn = LocalDateTime.now()

class MeetingCreated(
 val meetingId: MeetingId,
 val users: List[User],
 val title: String,
 val detail: String,
 val startAt: LocalDateTime,
 val endAt: LocalDateTime
) extends DomainEvent

class MeetingDeleted(
 val meetingId: MeetingId,
 val users: List[User]
) extends DomainEvent

trait DomainEventObserver:
 def respondTo[T &lt;: DomainEvent](event: T): Unit

class DomainEventPublisher(obs: DomainEventObserver*):
 def publish[T &lt;: DomainEvent](event: T): Unit =
 obs.foreach(_.respondTo(event))

// インフラストラクチャ層
class EmailSender extends DomainEventObserver:
 override def respondTo[T &lt;: DomainEvent](event: T): Unit =
 event match
 case e: MeetingCreated =&gt;
 e.users.foreach(u =&gt; send(u.email, e.title, e.detail))
 case e: MeetingDeleted =&gt;
 e.users.foreach(u =&gt; send(u.email, "ミーティング削除のお知らせ", "ミーティングが削除されました"))

 def send(to: Email, subject: String, body: String): Unit =
 println(s"email send to $to")

class EmailReserver extends DomainEventObserver:
 override def respondTo[T &lt;: DomainEvent](event: T): Unit =
 event match
 case e: MeetingCreated =&gt;
 e.users.foreach(u =&gt; {
 reserve(u.email, e.title, e.detail, e.startAt)
 reserve(u.email, e.title, e.detail, e.endAt)
 })

 def reserve(
 to: Email,
 subject: String,
 body: String,
 when: LocalDateTime
 ): Unit =
 println(s"email reserved sending to $to when $when")

// アプリケーション層
class MeetingService(
 meetingRepository: MeetingRepository,
 userRepsitory: UserRepository
):
 private val publisher = DomainEventPublisher(EmailSender(), EmailReserver())

 def reserve(
 organizerId: UserId,
 participantIds: List[UserId],
 startAt: LocalDateTime,
 endAt: LocalDateTime,
 title: String,
 detail: String
 ): Unit =
 val meeting =
 Meeting(
 organizerId,
 participantIds,
 startAt,
 endAt,
 title,
 detail
 )
 meetingRepository.save(meeting)
 val users = userRepsitory.getByIds(organizerId :: participantIds)
 publisher.publish(
 MeetingCreated(meeting.id, users, title, detail, startAt, endAt)
 )

 def reserveWithFollowed(
 organizerId: UserId,
 startAt: LocalDateTime,
 endAt: LocalDateTime,
 title: String,
 detail: String
 ): Unit =
 val organizer = userRepsitory.get(organizerId)
 val followers = organizer.followed
 val meeting =
 Meeting(
 organizerId,
 followers.map(_.id),
 startAt,
 endAt,
 title,
 detail
 )
 meetingRepository.save(meeting)
 val users = userRepsitory.getByIds(organizerId :: followers.map(_.id))
 publisher.publish(
 MeetingCreated(meeting.id, users, title, detail, startAt, endAt)
 )

 def remove(meetingId: MeetingId): Unit =
 val meeting = meetingRepository.get(meetingId)
 meetingRepository.delete(meetingId)
 val users =
 userRepsitory.getByIds(meeting.organizerId :: meeting.participantIds)
 publisher.publish(MeetingDeleted(meeting.id, users))</code></pre>

まとめ

ドメインイベントの導入

Scalaの型について（応用編その２）

例として、ミーティング予約サービスを考えます。このサービスは、ユーザからのミーティング予約リクエストを受けて、ミーティング情報を保存し、後から参照できるようにします。また、ミーティングを予約したユーザ（主催者）と、参加者全員に対して、メールを送信します。メールの送信タイミングは予約したタイミングと、ミーティング開始10分前、ミーティング終了10分前とします。 まずは適当に雑なコードを書いてみます。<pre><code>// ドメイン層
class UserId(val value: Int) extends AnyVal
class Email(val value: String) extends AnyVal

class User(val id: UserId, val email: Email)

trait UserRepository:
 def getByIds(ids: List[UserId]) =
 ids.map(User(_, Email("hoge@example.com")))

class Meeting(
 organizerId: UserId,
 participantIds: List[UserId],
 startAt: LocalDateTime,
 endAt: LocalDateTime,
 title: String,
 detail: String
)

trait MeetingRepository:
 def save(meeting: Meeting): Unit

// インフラストラクチャ層
class EmailSender:
 def send(to: Email, subject: String, detail: String): Unit =
 println(s"email send to $to")

class EmailReserver:
 def reserve(
 to: Email,
 subject: String,
 detail: String,
 when: LocalDateTime
 ): Unit =
 println(s"email reserved sending to $to when $when")

// サービス層
class MeetingService(
 meetingRepository: MeetingRepository,
 userRepsitory: UserRepository
):
 def reserve(
 organizerId: UserId,
 participantIds: List[UserId],
 startAt: LocalDateTime,
 endAt: LocalDateTime,
 title: String,
 detail: String
 ): Unit =
 val meeting =
 Meeting(organizerId, participantIds, startAt, endAt, title, detail)
 meetingRepository.save(meeting)

 def notify(user: User) =
 EmailSender().send(user.email, title, detail)
 EmailReserver().reserve(user.email, title, detail, startAt)
 EmailReserver().reserve(user.email, title, detail, endAt)

 val users = userRepsitory.getByIds(organizerId :: participantIds)
 users.foreach(notify)</code></pre> 面倒なのでファイル構成とかは考えてません。あと実際の処理も面倒なので全部printです。それと、メール送信の予約は実際には開始終了時間の10分前と言いましたが、本質と関係ない仕様なので一旦無視しています。

初回実装

今回は応用編の初回ということで、例として扱うドメインの要件と最初の実装を行いました。次回から少しずつリファクタリングしていこうと思います。

ミーティング予約サービス

Scalaの型について（応用編その１）

下限境界自体はそんなに難しくないのですが、どんな例を示すかで悩みました。というのも、ネットに出回っている他の記事を眺めていても、大体がListのようなデータ構造を定義しているだけで、「だったら普通にListを使えば良くない？下限境界なんて実際使うことなんてある？」という疑問に答えることができないと思ったためです。色々考えた結果、前回の例で使用したZooクラスを拡張するのが良さそうだと判断しました。 前回のZooクラスで、インスタンス化した後に<code>append</code>メソッドで別の動物を追加できるようにしたいとします。ただし、現状<code>animals</code>はListなので、後から要素を追加することはできません。そこで同じオブジェクトに要素を追加するのではなく、要素が追加された新しいオブジェクトを生成するようにします。 <pre><code>@main def main() =
 val zoo = Zoo(List(Dog(), Cat()))
 zoo.sound()
 val dogZoo = Zoo(List(Dog(), Dog()))
 dogZoo.sound()
 dogZoo.animals.foreach(_.run())
 val animalZoo = dogZoo.append(Cat()) // コンパイルエラー

class Zoo[T &lt;: Animal](val animals: List[T]):
 def sound(): Unit =
 animals.foreach(_.cry())

 def append(animal: T) =
 Zoo(animal :: animals)

class Animal:
 def cry(): Unit =
 println("crying")

class Dog extends Animal:
 override def cry(): Unit =
 println("bow wow!")

 def run(): Unit =
 println("running!")

class Cat extends Animal:
 override def cry(): Unit =
 println("meow")

 def walk(): Unit =
 println("walking")</code></pre> 上記のmain関数は6行目でコンパイルエラーを発生します。これは、<code>dogZoo</code>の型が3行目で<code>Zoo[Dog]</code>に固定されてしまっているためです。appendの引数の型パラメータがTになっており、<code>dogZoo</code>の場合はTがDogになるためです。しかし、Catを入れた場合は<code>Zoo[Animal]</code>を生成してほしいです。このような場合に、下限境界を用いることで、Zooに柔軟性を持たせることができます。下限境界は、<code>[T &gt;: U]</code>と指定します（Uが下限）<pre><code>@main def main() =
 val zoo = Zoo(List(Dog(), Cat()))
 zoo.sound()
 val dogZoo = Zoo(List(Dog(), Dog()))
 dogZoo.sound()
 dogZoo.animals.foreach(_.run())
 val animalZoo = dogZoo.append(Cat())

class Zoo[T &lt;: Animal](val animals: List[T]):
 def sound(): Unit =
 animals.foreach(_.cry())

 def append[U &gt;: T &lt;: Animal](animal: U) =
 Zoo(animal :: animals)</code></pre> 上記のバージョンではコンパイルエラーは起こらず、期待通り<code>animalZoo</code>の型は<code>Zoo[Animal]</code>になります。（なお、下限境界の設定のみではUはZooの型パラメータが満たすべき上限境界を満たしていないためZooのインスタンス化のところでコンパイルエラーになります。そのため下限境界だけでなく上限境界も同時に設定しています。） Zooの属性<code>animals</code>の型をAnimalのサブクラスに限定しながら、後から別のAnimalを追加した際にも型の柔軟性が保たれるような実装になりました。

下限境界

Scalaの型についてまとめてみた（その４）

型パラメータは基本的にどんな型が入ってくるかわからないというか、どんな型でも対応できる柔軟性を持たせるのが目的でした。しかし、場合によっては型にある程度制約を持たせたい場合があります。<code>[T &lt;: Type]</code>という型パラメータの指定をすると、TはTypeのサブ型であるという制約が課されます。例を示します。<pre><code>@main def main() =
 val zoo = Zoo(List(Dog(), Cat()))
 zoo.sound()
 val dogZoo = Zoo(List(Dog(), Dog()))
 dogZoo.sound()
 dogZoo.animals.foreach(_.run())

class Zoo[T &lt;: Animal](val animals: List[T]):
 def sound(): Unit =
 animals.foreach(_.cry())

class Animal:
 def cry(): Unit =
 println("crying")

class Dog extends Animal:
 override def cry(): Unit =
 println("bow wow!")

 def run(): Unit =
 println("running!")

class Cat extends Animal:
 override def cry(): Unit =
 println("meow")

 def walk(): Unit =
 println("walking")</code></pre> 上記で、<code>Zoo[T &lt;: Animal]</code>と定義されているので、Zooの型パラメータはAnimalもしくはそのサブ型であることが要求されます。このように定義することで、メソッド定義内でAnimal型のメソッド<code>cry()</code>を使用することができます。main関数の1行目の定数は、Zoo[Animal]型です。一方、3行目の定数はZoo[Dog]型です。個人的にはここがポイントだと思っていて、あくまでも型パラメータの型が可変になることで、5行目ではDog型のメソッドである<code>run()</code>を呼び出すことが可能になっています。<pre><code>class Zoo(val animals: List[Animal]):
 def sound(): Unit =
 animals.foreach(_.cry())</code></pre> 上記のように定義すると、上の<code>dogZoo.animals</code>は<code>List[Animal]</code>になってしまうため、<code>run()</code>を呼び出すことができなくなってしまいます。いわばDog型であるという情報を失ってしまうことになります。 上限境界を用いることで、型安全性と柔軟性を兼ね備えた実装が可能になることがわかりました。

上限境界

Scalaの型についてまとめてみた（その３）

前回の最後で、反変とは共変の逆であるという話をしました。反変の型アノテーションは、<code>Hoge[-T]</code>と定義します。UがTの子である場合、Hoge[U]はHoge[T]の「親」になります。物凄く不自然な感じがしますね。具体例を使って考えてみます。<pre><code>@main def main() =
 val animal = Animal()
 val dog = Dog()

 val fn1: Dog =&gt; Unit = listen
 fn1(dog) #=&gt; "listening to...\nbow wow!"

 val fn2: Animal =&gt; Unit = chase // コンパイルエラー
 fn2(animal)

def listen(a: Animal): Unit =
 println("listening to...")
 a.cry()

def chase(d: Dog): Unit =
 println("chasing!")
 d.run()

class Animal:
 def cry(): Unit =
 println("crying")

class Dog extends Animal:
 override def cry(): Unit =
 println("bow wow!")

 def run(): Unit =
 println("running!")</code></pre> Scalaでは関数型の引数のパラメータが反変として定義されています。そのため上記のmain関数の4行目は成功しますが、7行目はコンパイルエラーを発生します。listenは引数にAnimalを要求していますが、fn1として実際に実行されるときに渡されているのはDogです。Dog is AnimalなのでAnimalとしての要求にはもちろん応えられます。逆に、chaseは引数にDogを要求していますが、fn2として実際に渡されているのはAnimalです。そのためもし7行目でコンパイルエラーが発生しないなら、Animalに対してrunメソッドを呼び出そうとして実行エラーになっていたことでしょう。 ここで関数の型について考えてみると、fn1はDog =&gt; Unit型でしたが、代入されているのはlistenつまりAnimal =&gt; Unit型です。抽象化するとFn[Dog]がFn[Animal]と互換性がある、つまり親子関係でいうとFn[Dog]はFn[Animal]の親ということになり、型パラメータと親子関係が逆転していることがわかります。 一見不自然に見える反変ですが、場合によっては自然な定義となることもあることがわかりました。

反変

型アノテーションその２

Scalaの型についてまとめてみた（その２）

例として以下のコードを見てください。<pre><code>val animals = List[Animal](Dog(), Cat())
animals.foreach(_.cry())

abstract class Animal():
 def cry(): Unit

class Dog extends Animal():
 override def cry(): Unit =
 println("bow wow!")

class Cat extends Animal():
 override def cry(): Unit =
 println("meow")</code></pre> ※List[Animal]は型推論してくれるため本来は指定しなくても大丈夫です。このコードを見せられてもなんの違和感も感じないと思いますが、Listの各要素の型はAnimalなのに、DogやCatを入れても問題ないのはなぜでしょうか？それは、Listの型が共変の型パラメータになっているためです。共変の型パラメータは<code>class Hoge[+T]()</code>と定義され、UがTのサブ型である場合、Hoge[U]もHoge[T]のサブ型と判断されます。これにより、たとえ厳密に同じ型でなくても、Listの要素として追加できるようになり柔軟性が増します。 注意点として、共変を安全に定義できるのはイミュータブルなオブジェクトのみです。まず、配列は参照型なので以下のような挙動になるのはおわかりかと思います<pre><code>val ary = Array(1)
val ary2 = ary
ary2(0) = 2
println(ary(0)) #=&gt; 2</code></pre> 次に、以下のコードを見てください。<pre><code>@main def main() =
 val dogs = Array(Dog())
 val animals: Array[Animal] = dogs // コンパイルエラー
 animals(0) = Cat()
 dogs(0).run()
 
abstract class Animal:
 def cry(): Unit
 
class Dog extends Animal:
 override def cry(): Unit =
 println("bow wow!")
 
 def run(): Unit =
 println("running!")
 
class Cat extends Animal:
 override def cry(): Unit =
 println("meow")
 
 def walk(): Unit =
 println("walking")</code></pre> 実際にはmain関数の2行目でコンパイルエラーが起きますが、仮にArrayのパラメータが共変だったとすると以下のような不具合が発生します<ul><li>2行目でanimalsはArray[Animal]と定義されているので、dogsを入れることができます</li><li>同様に3行目でanimalsにCatを入れることも可能です</li><li>2行目でanimalsとdogsは同じオブジェクトを参照しているため、dogs(0)にはCatが入っています</li><li>4行目でdogs(0).run()を実行しようとしますが、dogs(0)の実態はCatなので、runメソッドが実装されておらず実行エラーになります</li></ul> ScalaではArrayは実際には共変ではなく非変として定義されています。非変の場合は厳密に同じ型でなければ互換性がないと判断されます。 他にも反変がありますがこちらは共変と全く逆で、UがTのサブ型である場合、Hoge[T]がHoge[U]のサブ型と判断されます。こちらは直感に反しますが、そのような定義に実用性はあるのでしょうか？ ・・・というわけで、次回に続きます

共変・非変について

変位指定アノテーションその１

Scalaの型についてまとめてみた（その１）

Entのスキーマファイルを元に生成したER図のリンクは以下のコマンドで作成できます。<pre><code>$ go run -mod=mod ariga.io/entviz ./path/to/ent/schema</code></pre> <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/23a1dab6624c4261b481810da2825a45/image.png" alt="">

TL;DR

go mod init で確認用プロジェクトを初期化します。<pre><code>$ go mod init github.com/rotemtam/ent-blog-example</code></pre> 新しいプロジェクトが作成されたことを確認します。<pre><code>go: creating new go.mod: module github.com/rotemtam/ent-blog-example</code></pre>

1. go mod initで確認用プロジェクトを初期化する

Entを使用してアプリケーション・データ・モデルを作成するため、go get を使って取得しましょう。 <pre><code>$ go get -u entgo.io/ent@master</code></pre>

2. アプリケーション・データ・モデルを作成する

Ent CLI を使用して、このチュートリアルで扱う2種類のエンティティ（UserとPost）のモデルを初期化します。 <pre><code>$ go run -mod=mod entgo.io/ent/cmd/ent new User Post</code></pre>

3. Ent CLI を使用して２種類のエンティティのモデルを初期化する

./ent/schema 配下にあるpost.go と user.go にそれぞれ以下を追記します。 user.go<pre><code>// Fields of the User.&nbsp;&nbsp;
func (User) Fields() []ent.Field {&nbsp;&nbsp;
&nbsp;&nbsp;return []ent.Field{&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;field.String("name"),&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;field.String("email").
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Unique(),&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;field.Time("created_at").
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default(time.Now),&nbsp;&nbsp;
&nbsp;&nbsp;}&nbsp;&nbsp;
}&nbsp;&nbsp;
&nbsp;&nbsp;
// Edges of the User.&nbsp;&nbsp;
func (User) Edges() []ent.Edge {&nbsp;&nbsp;
&nbsp;&nbsp;return []ent.Edge{&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;edge.To("posts", Post.Type),&nbsp;&nbsp;
&nbsp;&nbsp;}&nbsp;&nbsp;
}</code></pre> post.go<pre><code>// Fields of the Post. 
func (Post) Fields() []ent.Field { 
 return []ent.Field{ 
 field.String("title"), 
 field.Text("body"), 
 field.Time("created_at").
 Default(time.Now), 
 } 
} 
 
// Edges of the Post.
func (Post) Edges() []ent.Edge { 
 return []ent.Edge{ 
 edge.From("author", User.Type). 
 Unique(). 
 Ref("posts"), 
 } 
}</code></pre>

4. 生成されたschemaファイルに設定を追記する

以下のコマンドを実行し、ER図のリンクを生成してブラウザで確認します。<pre><code>$ go run -mod=mod ariga.io/entviz ./ent/schema</code></pre> 以下のようなページが開ければ完了です。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c355cb8ee1b640ea973aa5f88f22d166/image.png" alt="">

5. コマンドを実行してER図のリンクを生成する

実際に使ってみた

schemaファイルさえ書いていればコマンド一つでER図が生成できるので非常に便利な機能でした。Entはコンスタントにこういった便利な機能のアップデートが行われているので、これからも定期的にリリースノートをチェックして追っていきたいと思います。

Go言語のフレームワークentにER図生成ツールが導入されたので使ってみた

こんな感じでホバーで型定義が確認できるところがいいですね。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ce10752003984656b09e5d543258de21/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2018.57.49.png" alt="">

type

次にinterface<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/d4ed6b36ffdb4b4f9992d7f904359734/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2018.57.28.png" alt="">こっちはホバーしても確認はできません。 ただし、interfaceは継承することができます。 継承(extends)<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/cbea8ed2132d44c19529fbb68922f0f5/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2019.03.03.png" alt="">typeでは型の継承はできないです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/22aed711d8b24e0193836c2f071adf6d/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2019.14.53.png" alt="">

interface

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/3e7f34b67601449482dc74dfb4a60c4a/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2019.09.53.png" alt="">labelを取り除いた型定義になりました。こちらはinterface→typeでの定義が可能です。

Omit

<pre><code>interface Hoge {
 className?: string;
 label: string;
 onClick?: () =&gt; void;
};

// 複数指定するときは|を使用
type Huga = Pick&lt;Hoge, "label" | "className"&gt;;</code></pre>結果<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b13533ee1e344288bb51581f4d0fc708/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2019.24.34.png" alt="">

Pick

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/d51c0105ab9f4642a17f14b8d0bade29/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2019.20.34.png" alt="">stringかnumberか判断してくれます。

型宣言の条件分岐

?がついている型は宣言が任意ですが、指定がない場合の初期値を設定することができます。<pre><code>interface Hoge {
 className?: string;
};</code></pre>宣言<pre><code>Page.defaultProps = {
 className: null,
};</code></pre>

defaultProps

おまけ

typeScriptが使われる現場がかなり多いと思いますので不要な型宣言を増やさないように実装していきたいですね。

typeScriptのtypeとinterfaceの違い

公式<a href="https://github.com/pmndrs/zustand" target="_blank" rel="noopener noreferrer">https://github.com/pmndrs/zustand</a> 軽量なグローバル管理ライブラリです。Reduxを使用するとめんどくさいので業務でも個人開発でも使用してます。<pre><code>import { create } from 'zustand'

const useBearStore = create((set) =&gt; ({
 bears: 0,
 increasePopulation: () =&gt; set((state) =&gt; ({ bears: state.bears + 1 })),
 removeAllBears: () =&gt; set({ bears: 0 }),
}))</code></pre> <pre><code>function BearCounter() {
 const bears = useBearStore((state) =&gt; state.bears)
 return &lt;h1&gt;{bears} around here ...&lt;/h1&gt;
}

function Controls() {
 const increasePopulation = useBearStore((state) =&gt; state.increasePopulation)
 return &lt;button onClick={increasePopulation}&gt;one up&lt;/button&gt;
}</code></pre>

zustand

公式<a href="https://storybook.js.org/" target="_blank" rel="noopener noreferrer">https://storybook.js.org/</a> コンポーネントごとに単体テストが簡単にできるようになります。個々にstorybookのファイルを作成しないといけないので業務ではリソース次第で採用するといいと思います。 こんな感じのページが生成されます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/39f5d58dc5504b50ae02649bf20f3281/mdx-example.png" alt="">

Storybook

classに直接書いていくとどうしても可読性が下がってしまうので必要な時に使用するといいと思います。(tailwindには@applyというオプションもあるのですが、ホバーでスタイル確認できないので 簡単なのですぐ使えると思います。<pre><code>import { tw } from "tw-tag";

// ()で囲むとホバー時にスタイルが確認できる。
const error_message = tw(`text-red-600 text-sm mb-2`);

&lt;p className={`${error_message} mx-auto`} style={{ whiteSpace: "pre-wrap" }}&gt;
	{errorMessage}
&lt;/p&gt;</code></pre>

tw-tag

いかがでしたでしょうか？ 他にも便利なライブラリがたくさんありますので、探してみるのもいいかもしれませんね。

【React】使ってみていい感じだったライブラリ

暗号化<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/38a3e35a0c8d4d679607204542419512/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2016.15.54.png" alt="">結果<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/3fdc245d6ba84317961702a32887d948/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2016.17.37.png" alt="">Wklv lv d whvw phvvdjh iru wkh Fdhvdu flskhu.これが暗号ですね。 これをリフレクターというもので復号化してみます。 リフレクター<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/d4ce4402851047248d03eb70dc3584c7/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2016.21.28.png" alt="">結果<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/60d90a5a726748a2abdf38d560dc6327/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-01-04%2016.22.06.png" alt=""> ただ反転してるだけなんですけどね

実装

ネットが普及してる今のご時世ではセキュリティ対策はエンジニアにとっても大事なものとなってますね。 イミテーションゲームという映画ではこれより遥かに複雑なエニグマという暗号が使われてたり(初めてコンピュータで暗号を復号化されたのもエニグマだったような.... 興味のある方は暗号の歴史から追うのも面白いかと思います！

JavaScriptでシーザー暗号を実装してみる

これはよく見かけるmargin-top<pre><code>&lt;div className="flex justify-center items-center p-12"&gt;
 &lt;h1&gt;見出し&lt;/h1&gt;
 &lt;p className="mt-2"&gt;hoge&lt;/p&gt;
 &lt;p className="mt-2"&gt;huga&lt;/p&gt;
&lt;/div&gt;</code></pre> gapを使うと均等に余白を取ってくれます。<pre><code>&lt;div className="flex justify-center items-center p-12 gap-2"&gt;
 &lt;h1&gt;見出し&lt;/h1&gt;
 &lt;p&gt;hoge&lt;/p&gt;
 &lt;p&gt;huga&lt;/p&gt;
&lt;/div&gt;</code></pre> イメージとしてこんな感じです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/664a5a1fdb4547caabea818a4cf95594/Group%2067.png" alt="">

marginに頼りすぎている

tailwindのdocsにも書かれていますがw-4やw-80などの数字はrem指定です。(w-4 = width: 1rem; / 16px /fullや1/2などは%指定となってます。<a href="https://tailwindcss.com/docs/width" target="_blank" rel="noopener noreferrer">https://tailwindcss.com/docs/width</a> よく見かけるのが <pre><code>&lt;div className="w-full"&gt;
 &lt;p&gt;hoge&lt;/p&gt;
&lt;/div&gt;</code></pre>親が%はダメです。基準としてみるwidthがないのでダメです。 親で100%を取りたい場合はscreenを使いましょう。<pre><code>&lt;div className="w-screen"&gt;
 &lt;p&gt;hoge&lt;/p&gt;
&lt;/div&gt;</code></pre>

基準のない%指定

背景だけ50%透過したいとします。opacityを使うと子要素にも透過が適用されてしまいます。<pre><code>&lt;div className="w-screen hscreen bg-sky-500 opacity-5"&gt;
 &lt;p&gt;hoge&lt;/p&gt;
 &lt;p&gt;huga&lt;/p&gt;
&lt;/div&gt;</code></pre> bg-sky-500/50で背景のみ50%透過することができます。<pre><code>&lt;div className="w-screen hscreen bg-sky-500/50"&gt;
 &lt;p&gt;hoge&lt;/p&gt;
 &lt;p&gt;huga&lt;/p&gt;
&lt;/div&gt;</code></pre>

opactyを単体の要素にのみ適応

よく見かけるレイアウト構造を例に紹介していきました。できるだけ親要素がclassを持っている方が分かりやすいかなと思います。

レイアウト構造を考え直してみる

App Store リンク：<a href="https://apps.apple.com/jp/app/daisydisk/id411643860?mt=12" target="_blank" rel="noopener noreferrer">https://apps.apple.com/jp/app/daisydisk/id411643860?mt=12</a> 料金：1500円 概要：Macのストレージ使用状況を階層構造で可視化してくれるアプリです。どのファイル・フォルダにどれくらいの容量が使用されているのかが一目でわかり、そのままアプリ上から削除することも可能になっています。ユーザーインターフェースが非常にシンプルで洗練されているので、面倒だったデータの整理が少し楽しくなり重宝しています。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/f6411a398bed496cb13edb306129e145/Screenshot%202024-01-04%20at%2013.21.54.png" alt="">

DaisyDisk

App Store リンク：<a href="https://apps.apple.com/jp/app/as-timer/id512464723?mt=12" target="_blank" rel="noopener noreferrer">https://apps.apple.com/jp/app/as-timer/id512464723?mt=12</a> 料金：無料 概要：タイマー機能のみの非常にシンプルなアプリです。MacOSのタイマーにはない無音アラームの機能やウインドウの最前面に固定する機能など、単純ですが意外となかった機能が備わっていて優秀です。

AS Timer

GitHub リンク：<a href="https://github.com/SelfControlApp/selfcontrol" target="_blank" rel="noopener noreferrer">https://github.com/SelfControlApp/selfcontrol</a> 料金：無料 概要：あらかじめ登録しておいたサイトを設定された時間の間閲覧できなくなるアプリです。別途で曜日ごとに時間設定できる設定アプリ(<a href="https://github.com/AlexanderDickie/auto-selfcontrol-rs" target="_blank" rel="noopener noreferrer">こちら</a>)もあるので、そちらも合わせて使用すると手間が省けて生産性爆上がりです。本業終わりの自学自習や副業の時に気を抜くとついつい関係のないサイトやYoutubeを見てしまうなんて方はぜひ使ってみてください。

SelfControl

非常にざっくりとした紹介でしたがいかがだったでしょうか。個人的に一番オススメなのは最初に紹介したDaisyDiskです。今回紹介したアプリをまだ使ったことがない方はぜひ導入して試してみてください。

BuildersIO produced by YOKU