FLINTERS Engineer's Blog

FLINTERSのエンジニアが綴る技術ブログ

ドメイン駆動設計(DDD)との格闘 - 突然DDD実践チームにPOとして参加することになったら

こんにちは、株式会社FLINTERSで企画職 (Product Owner、ProductManager、ProjectManager、雑用係などの総称)として働く加藤と申します。 私は、主に、インターネット広告代理店などデジタルマーケティングを実践されている企業へ、Yahoo!GoogleFacebookなどの広告媒体が提供するAPIなどを活用した、業務用のアプリケーションを開発提供するお仕事に携わっております。

私の勤める会社は、株式会社セプテーニ・オリジナルから、2021年1月4日をもちまして、 株式会社FLINTERS(読み:フリンターズ)に社名変更し、「FLINT=火打ち石」を語源として、「未来につながる火を灯そう」をミッションに掲げて気持ち新たに頑張っております。ただいまFLINTERSでは、ブログ投稿強化月間ということで、私も恥ずかしながら駄文を投稿させていただきます。

この投稿の内容

ドメイン駆動設計(DDD)に突然、プログラミングとは無縁だった社員が放り込まれて四苦八苦しながら、ドメイン駆動設計(DDD)を実践する開発チームとお友達になるコツを紹介します。弊社及びグループ会社の開発関係者の方へ、研修や勉強会として提供させて頂いていた内容を少し改変しながら、数回に分けてお届けしたいと思います。 初回となる今回は、ドメイン駆動設計(DDD)との出会いと苦悩についてです。次回以降に、ユビキタス言語(Ubiquitous Language)、ドメインの発見の仕方、境界づけられたコンテキスト(bounded context)、コンテキストマップなどについて紹介していきたいと思います。

この記事の想定読者

  • 開発者出身ではない、Product Owner、ProductManager、ProjectManagerの方

  • ドメイン駆動設計(DDD)を取り入れたいけれど、開発者出身ではない意思決定者がなかなか理解を示してくれない方

  • FLINTERSで企画職として働いてみたい、そこのあなた

あくまで、私の体感したコツなどをご紹介するものであり、誤っている点など多々あるかとおもいますが、その場合は優しくご指摘くださいませ。

ドメイン駆動設計(DDD)との出会いと苦悩

当時発足間もなかった、グループ会社であったセプテーニ・オリジナルへ出向したのが2015年10月。

弊社では、

所属する企画者・エンジニアの指針となるよう、現在の我々の目指すところ/我々が取っている行動の理由/我々が求める姿勢、を文章化した

技術指針を定めており、少しずつ改変を加えながら現在の姿となっています。 www.flinters.co.jp

私が参加した当時から、この技術指針において、原則として開発チームはドメイン駆動設計(DDD)を採用することになっており、私が配属された開発チームももちろんドメイン駆動設計(DDD)を採用しておりました。興味のあった開発会社へ異動が決まった私は、意気込んで、上司や同僚から薦められた、アジャイル開発やScrumなどの初心者向けの文献を読んだり、社内のドキュメントを読んだりしながら過ごしていたのですが、なぜか、ドメイン駆動設計(DDD)については上司や同僚の企画職から学ぼうとすると、「ま、DDDは、今すぐじゃなくてもいいんじゃないかな」、「企画職には直接的にはあまり関係ないよ」などと、ちょっと皆、曇り顔。

ドメイン駆動設計(DDD)の学習への挑戦と挫折

でも、技術指針では以下のように、ドメイン駆動設計(DDD)について記述されており、「チーム全員で」、「エンジニア以外にも」、「プロダクトオーナーが」などと記述されており、とても自分に無関係なものとは思えません。

DDDを採用するのはチーム全員で要件の芯を捉え続けるため

我々はドメイン駆動設計を積極的に採用します。

ドメイン駆動設計はユビキタス言語という言葉と実装を一致させる言語を用いてビジネス要件の芯を設計の中核におく手法です。

「エンジニア以外にも翻訳不要で伝えることができる」「設計と実装に対する価値観が共有できる」という特徴があり、チーム全員で要件の芯を捉える助けになることを期待しています。

具体的には、やらねばならないことのコストをプロダクトオーナーが認識しやすくなる/レビューや仕様検討時に、言葉と実装が一致しているか、というチェックを行えるようになる/設計や概念がまずい場合、言葉にすると自然と大仰に成り危険な感じになる、といった効能を期待しています。 なお、“レイヤードアーキテクチャを採用する”ではないため、上記効能を維持出来るアーキテクチャであればどの手法でも構いません。

そこで、企画職ではなく、開発チームにDDDについて学びたいと伝えると、、、はい、紹介されたのは鈍器でした

実践ドメイン駆動設計

実践ドメイン駆動設計

ドメイン駆動設計(DDD)を行う方はEric Evans本とその実践について触れたこの2冊は必携の本であると今では理解できますが、1冊で数百ページを超えており、通勤カバンに入れて自宅と会社を往復するだけで肩が抜けそうになります。鈍器あるいは、デスクでお昼寝するときの枕に最適なサイズです。ただ、いくら枕にしていても妖精が読み上げてくれるわけではないので、なんとか最初から読もうとして、文字面を目で追っていくのですが、惨敗です。まったく内容が頭に入らなかったといっても過言では有りません。 「ま、DDDは、今すぐじゃなくてもいいんじゃないかな」と言っていた上司の言葉は確かに正しかったと思います。

また薄い本として、社内で通称Quicklyと呼ばれる、素晴らしい日本語訳、しかも無料のドキュメントがあるのですが、こちらは、まったくの開発プロジェクトの初心者にとっては、上記の2冊の鈍器より、さらに難解だと思います。ある程度理解されている方が、短時間での知識の再定着などを目的に読むといいかなあと思います。

Domain Driven Design(ドメイン駆動設計) Quickly 日本語版

プログラマードメイン駆動設計(DDD)のすべてを理解することは無理である

その後、数年かけて、なんとなく非開発者として、ドメイン駆動設計(DDD)との付き合い方を身につけることができたのは、近年まで弊社の技術メンターをしていただいていた、かとじゅん氏 が、数度にわたり社内向けにセミナーを開催して頂いていたり、新規の開発プロジェクト立ち上げ時に設計のサポートをしていただいたおかげだと思います。また、この有用性を実感するようになったのは、ベトナムハノイにあるグループ会社であるSEPTENI TECHNOLOGY(FLINTERS VIETNAMに商号変更予定)と、国境を超えた開発プロジェクトに参加するようになってからです。

ここで、ズバリ断言します (と、著名なプログラマーな人をマネてみた)。プログラミングの知識や経験が無ければ、ドメイン駆動設計(DDD)のすべてを理解することは無理です。この考え方は、オブジェクト指向プログラミング(object-oriented-programming OOP)と深く結びついており、その考え方や技法を実践できなければ、ドメイン駆動設計(DDD)を理解し、実践することは、不可能です(もちろん、超天才の方とかは別だと思います)。

ただし、非開発出身の企画職としても、開発チームがドメイン駆動設計(DDD)を実践し、よい開発をすることに貢献することはできます。貢献できるどころか、開発チームが成功するためには企画職が適切に価値を発揮することが不可欠です。

企画職に求められるドメイン駆動設計(DDD)への貢献

おそらく、ドメイン駆動設計(DDD)の開発プロジェクトへ企画者として参加する場合、ドメイン (一旦、ここでは、その開発プロジェクトで解決したいビジネス上の課題というような定義にしておきましょう)にたいして、そのエキスパートである、または、相対的にチーム内で知見があり、発注者・利用者の中のドメインエキスパートから課題や知識をヒアリングし、ソフトウェアで解決できるように落とし込んでいくことが期待されていると思います。

こうした、期待に応えるために、企画職として実践できるようになっておきたい、ドメイン駆動設計(DDD)の手法は4つです。

  1. ユビキタス言語の発見・作成・普及
  2. 広義のドメイン・狭義のドメインの発見・作成
  3. コンテキスト境界の発見・作成
  4. コンテキスト境界同士の関係性の発見・作成

次回以降では、具体的に、この4つの手法について、企画職としてどう取り組んでいくかということを紹介していきたいと思います。

知っておきたいエンジニアリング組織論

こんにちは。業務効率化と組織論が好きな新卒 3 年目の清水(@_smzst)です。「エンジニアリング組織論への招待」を読んで、これまでの自身の経験と紐づいて強烈な学びと納得感が得られたのでぜひみなさんにも知って欲しいと思いまとめてみました。

今回は第 1 章の「思考のリファクタリング」に絞っています。もし、この内容がいいなと思ったらぜひ書籍を手にとってみてください。きっと役に立つはずです。

エンジニアリング組織論を通して組織やチーム全体が共通の認識を持ち、お互いの弱みを補い強みを引き出し合う共同体としてより大きな力を発揮する… このブログがそのきっかけとなればいいなと思っています。

続きを読む

会社名変更のお知らせ

f:id:septeni-original:20210104114450p:plain

  このたび2021年1月4日をもちまして、株式会社セプテーニ・オリジナルから、 株式会社FLINTERS に社名変更することとなりました。


新会社名: 株式会社FLINTERS (読み:フリンターズ)
英語表記: FLINTERS, Inc.
 
FLINTERSは、「FLINT=火打ち石」を語源として、「未来につながる火を灯そう」をミッションに掲げた社名となります。
今後とも変わらぬ御愛顧を賜りますようお願いします。

ちょっとした文字列変換処理を書いた話(あるいはplay-functionalの機能を利用してみた話)

こんにちは。張沢です。

業務で特定の型のインスタンスを文字列に変換する処理を書いた際に、play-functionalの機能を利用したときの話を書いてみます。

例えば、あるオブジェクト(case classなど)があった場合、以下のような仕様の文字列が生成されるような実装について考えます。*1

  • key=value の形式で出力する
  • 各keyは、. で区切られる
  • 配列やリストの場合は、keyの後にzero-based indexを [] で囲んで付ける

具体例は以下の通りです。

case class User(id: Long, name: String, telephoneNumbers: Seq[String])

例1:

val user = User(1L, "user_1", Seq("000-0000-0000", "111-1111-1111"))
user.id=1
user.name=user_1
user.telephoneNumbers[0]=000-0000-0000
user.telephoneNumbers[1]=111-1111-1111

例2:

val users = Seq(
    User(1L, "user_1", Seq("111-1111-1111")),
    User(2L, "user_2", Seq("222-2222-2222"))
)
users[0].id=1
users[0].name=user_1
users[0].telephoneNumbers[0]=111-1111-1111
users[1].id=2
users[1].name=user_2
users[1].telephoneNumbers[0]=222-2222-2222

*1:業務で実装した文字列の仕様は、この記事での仕様例とは異なります

続きを読む

ScalaMatsuri 2020 に今年も出展しました!

株式会社セプテーニ・オリジナルは今年も将軍スポンサーで、通算5回目になりました。

f:id:Nomad_Blacky:20201104183747p:plain

メインセッション「Re-architechting in GANMA!」で登壇しました

GANMA! チームでバックエンドシステムの開発/運用を担当してる青山(@aoiroaoino)です。

今回発表した内容は、ここ一年くらいで実施した GANMA! チーム内でのリアーキテクチャに関する取り組みをまとめたものです。 サービスのリリース直後は最新のツール/最新の考え方のもと最善を尽くして開発されたものだったかもしれませんが、 時間の経過によって陳腐化してしまい、機能開発を行っていく上でこれらの悪影響が無視できない状態となってしまっていました。 それらをどのようにして解消していったのか、その詳細は以下の資料や後ほど公開される動画をご覧ください。

speakerdeck.com

今回の発表までで改善活動で全てが完了したわけではありません。 システムが稼働し続ける限り常に進化を続けなければまた近い将来、同様の状態になってしまうことでしょう。 いかにして技術的負債を制御下に置くか、常日頃からの取り組みが重要です。

今後もこういった活動を通じて得られた知識/知見をチームメンバーで積極的にアウトプットしていきたいと思います。

スポンサーブース で出展しました

スポンサーブースのレポートを担当します、門脇 (@nomadblacky) です!

セプテーニ・オリジナルBOOTHでは以下のセッションを発表しました。

LT: Slinky で Scala.js製 React Webアプリケーションをつくったはなし

speakerdeck.com

Scala.js の React.js フレームワークである Slinky を用いて実際にWebアプリケーションを作成した過程とそのノウハウについて紹介いたしました。

セプオリ史上初!技術も仕事も会社のことも、ココだけの話を大公開!社員が赤裸々に語る『セプオリラジオ』!

セプオリラジオと称して、セプオリで働くエンジニアにインタビューを行いました。
弊社の技術指針の話や、どんな社員が所属して仕事をしているのか、そして今ホットなリモートワークに対する取り組みなど、ベテランから若手まで、またエンジニアに留まらず多様な職種の方々の生の声を皆様にお届けしました!

LT: 大変だよ、Tagless-final パターン

speakerdeck.com

GANMA! のバックエンドエンジニアである青山さん(@aoiroaoino)の発表です。 言語内DSLを構築する手法である Tagless-final を導入した際の悩みどころなどをお話しました。

熟練Scalaエンジニアの匠の技術を盗め!リアーキテクティングの技をライブで披露します!

Scala研修で作成されたPlayFramework製のWebアプリケーションをビジネスの成長を見据えた、モノリスからモジュラモノリスへとリアーキテクトしていく様子をライブコーディングでお伝えしました。

裏セプオリラジオ

上記のリアーキテクティングライブのあと、雑談している間に話が盛り上がり裏セプオリラジオが始まっていました😂 最近業務で取り組んでいるScalaを使った開発の話から、ScalaからAWS CDKを扱う話になりました。 こちらは以前、scala-tokyo というイベントで発表していますので興味がある方はこちらをどうぞ。

speakerdeck.com

技術読本を配布しました

f:id:Nomad_Blacky:20201104184300p:plain

ダウンロード

毎年恒例の「技術読本」を今年も公開しております!

弊社エンジニアの知見をたっぷり凝縮した読み応えのある本になっていますので、上記のURLからダウンロードしてぜひご覧ください!!

最後に

セプテーニ・オリジナルBOOTHに参加いただいたみなさま、ありがとうございました。
また、初のオンライン開催だったにも関わらず快適なイベントを提供いただいた、ScalaMatsuriのスタッフの方々にも多大なる感謝を申し上げたいと思います。ありがとうございました。
今後ともセプテーニ・オリジナルでは日本のScalaコミュニティの一員として貢献していきたいと思っております。

また来年もお会いしましょう!