1
/
5

ChatWorkとネクストビートのDDDに対する考え方~Nextbeat (衣笠) x SmartNews(瀬良) x ChatWork(かとじゅん)トークセッションvol.2-2

みなさんこんにちは、ネクストビート編集部です。

今年3月に開催された ScalaMatsuri (https://2018.scalamatsuri.org/) の後日イベント「NextMatsuri」を5月12日にネクストビートの恵比寿本社で開催いたしました。当日、スマートニュースの瀬良様と、ChatWorkの加藤様にご来社頂き、当社CTOの衣笠とトークセッションを開催させていただいたのですが、その内容が非常に濃かったので、何回かに分けて配信させて頂いております!

過去記事:

【エンジニアイベントvol.6】3社はなぜScalaの導入に至ったのか~Nextbeat (衣笠) x SmartNews(瀬良) x ChatWork(かとじゅん)トークセッション①~ | nextbeat engineer
皆さんこんにちは、ネクストビート広報チームです。 3月16日から18日の3日間にかけて開催された ScalaMatsuri ( https://2018.scalamatsuri.org/ ) の後日イベント、「 NextMatsuri ...
https://www.wantedly.com/companies/nextbeat2/post_articles/120681


ChatWorkとネクストビートのDDDに対する考え方~Nextbeat (衣笠) x SmartNews(瀬良) x ChatWork(かとじゅん)トークセッションvol.2-1 | nextbeat engineer
みなさんこんにちは、ネクストビート編集部です。 今年3月に開催された ScalaMatsuri (https://2018.scalamatsuri.org/) ...
https://www.wantedly.com/companies/nextbeat2/post_articles/135611




今回は、登壇者とイベント参加者様のQAセッションの模様を配信します。

Q- DDD は開発者と事業担当者が密に連携し良いものをつくることを目指すと思いますが、最初から良いモデルが作れるとは限らず、現実的にはあとから洗練をさせていくと思っています。とはいえ、クラス名やテーブル名など、後から変えづらいところもありますよね。その変えづらい部分を、変更しやすくするには、どうすればよいのでしょうか?

加藤:

一般的に言われるDBスキーマの変更のしにくさは、どこの会社でも共通問題で、トレードオフをどこでやるかという話になると思います。

スキーママイグレーションの戦略によって手法は変わると思いますが、イミュータブルにテーブルデータを入れ替える方法もありますし、レコード件数が多くて時間が掛けられない場合はALTERする場合もありますね。

ドメインモデルを重視した設計はスキーママイグレーションは大変ですが、絶妙な妥協ができるようにトレードオフする条件を探るという感じになると思います。万能な解決策はどこかでほころびがでると思っていて、どこで妥協できるか探った方法の方が現実的であると思っています。

衣笠:

ドメイン間のコンテキストという限られた境界みたいなところをやっていくと思いますが、Scala もつきつめていくと、ライブラリーの細分化や、MVC Framework から マイクロサービス系の Akka, Lagom などに切り分けてしていく手法があると思うのですけど、できるだけコンテキスト自体を肥大化させないでリプレースをかけられる状態を維持しておくというのも1つの手かもしれないです。

コンテキストをマイクロサービスにしてしまって、変えたいときはそのコンテキストごとリプレースかけてしまうとか、そういうのも手かもしれないですね。

瀬良:

DDDっぽくないかもしれないですが、私もそういうことやったことがあります。

例えば、昔設計ミスしてしまった可能性もあるような名前や、結果的にどんどん意味が変わっていく部分、本当はこの名前だと紛らわしいところ等があると思います。そういった問題箇所の一部だけ勝手に変えてしまうと、全体で見たときに意味が分からなくなってしまうので、アプリケーションコードにそういう変更を加えるとなったときに、しっかりやりきるのが大事だと思います。

誰かが自分の考える綺麗なモデルにしたつもりでも、勝手に中途半端にやってしまうと、全体としては結局わかりにくくなっただけみたいになってしまいます。

マイクロサービスのように分けてしまうのも1つの手だし、分けないけどアプリケーションコードの中でそういう例をつくる場合は、ドキュメンテーションなど合意形成をしっかりやるのが重要だと思います。

私が前やったときは、ユーザーのアカウント情報を抽象化する変更について、勝手にこうだと思い込んでやるのではなく、課題をヒアリングした上で仕様をまとめあげました。

こういったまとめあげた考え方を、今日入社した人にもわかりやすくドキュメンテーションされていることも重要だと思っています。それが継続的にアップデートされていくという環境を作るのも重要でしょうね。

衣笠:

巨大システム、サーバーが何千台となる場合は、ユーザーごとにクラスターを分け、このユーザーは何番のクラスターに該当するから、この指定のサーバーにアクセスをするようにロジックできりわけていて、ファーム(※1)ごとにアプリケーションのレベルをこっちは新しいもの、こっちは古いものと配置しておき、ファームに対してマイグレーションをかけるというのはよくやっていました。徐々に古い方から新しい方に変えていくという方法です。

アクティブ、非アクティブなユーザーがいると思うので、非アクティブなユーザーからマイグレーションを試して、アクティブなユーザーは安定してからマイグレーションするという考え方もあると思います。

(※1)クラスターのシャード

続きは【ChatWorkとネクストビートのDDDに対する考え方トークセッション②-3】をご覧ください!


興味をお持ちいただけた方は、Wantedlyで掲載中の募集職種から、ご連絡ください。Wantedly以外の経路より優先して選考のご案内を差し上げます。選考ではなく、まずは話を聞いてみたいという方も、現時点でご関心がある職種の募集ページからご連絡お願いいたします。

株式会社ネクストビートでは一緒に働く仲間を募集しています
44 いいね!
44 いいね!
同じタグの記事
今週のランキング
株式会社ネクストビートからお誘い
この話題に共感したら、メンバーと話してみませんか?