Web APIを開発するときにクリーンアーキテクチャやDDDなどの設計手法を取り入れることが流行っています。
ですが、プロダクト開発の初期フェーズではプロダクトの仕様が固まっておらず、巷で良いとされている設計手法をきちんと採用することは難しいことがあります。

良いとされる設計手法を取り入れたい理由はコードの品質を高くするためです。
無理に良いとされる設計手法を採用するとコードの品質が下がる場合があり、コードの可読性が下がったり、コードを変更しづらくなったりします。

Web APIの開発フェーズによって「適度」に良いとされる設計手法を取り入れ、場合によってはチームルール等のコード以外の仕組みを導入することでコードの品質を高めることができます。
本セッションでは、Web APIの開発の初期フェーズでどのような設計手法を取り入れて良かったかについて

• 合同会社DMM.comでの0->1のプロダクト開発
• DMM Platformのマイクロサービスのソフトウェアアーキテクチャのレビュー
• スタートアップへの技術支援
  を通して得た経験を元に説明します。

本セッションでは開発初期のWeb APIに焦点を当てて話しますが、それ以外のWeb APIの開発でも取り入れられる考え方なので、ぜひご視聴ください。

私がDDDに出会ったのは2014年です。
そのころはDDDの情報も少なく、試行錯誤しながらDDDに向き合ってきました。
思い返すと「DDD理解した」と「DDD分からん」を繰り返してきたように思えます。
今回の発表では私の経験をベースに「なぜDDDが難しいのか」「どうすればできるようになるのか」を設計原則や良いコードの定義を交えて説明しようと思います。

Rustがオブジェクト指向言語なのかは意見が分かれるところです。一方で、Rustにはクラスや継承がないと言ったことから、他のオブジェクト指向言語からすると躓きやすいポイントがあるのも事実です。本セッションでは、他のオブジェクト指向言語をメインに扱って来たエンジニアがRustに入門する際に躓きやすいポイントや注意すべきポイントを中心にお伝えします。
講演者のスタンスとしては、Rustの良さを使えたいと思っているため、他のオブジェクト指向型言語と比較した際のRustの言語仕様のメリットもお話したいと思います。他のオブジェクト指向言語をメインで扱ってきたエンジニアにとっては、オブジェクト指向言語と相性のいいアプリケーションアーキテクチャがRustでも実装可能なのか？と言った点も気になるところでしょう。講演者の本番環境ではRustアプリケーションの運用経験も踏まえて、講演者がどのようなアーキテクチャを選択してるのか、そのアーキテクチャでの良かったポイントや困ったポイントなどもお伝えします。
また、Rustをよりオブジェクト指向らしく扱うにはどうすればいいのか？と言った点も思考実験として扱いたいと思います。

全体アジェンダ構成は以下の通りです。
・Rustとオブジェクト指向にまつわる様々な議論
・オブジェクト指向とは
・Rustがオブジェクト指向ではないと言われる理由
・オブジェクト指向言語エンジニアがRust入門する際に気をつけるべきポイント
・Rustとアプリケーションアーキテクチャ
・Rustをよりオブジェクト指向らしく扱うためには

オブジェクト指向のひとつの潮流である抽象データ型をベースとする考え方は、データとそれに関連するロジックを一体化し、ユーザー定義型として利用するアプローチを示します。これはモジュール機構と型システムの融合、あるいはモジュールの第一級オブジェクト化として捉えることができます。

他方、それによって実装されたアプリケーションを稼働させるインフラに関しては、クラウドネイティブ技術の進展に伴い、Docker や Kubernetes を使用してコンテナベースの運用をすることは以前に比べて一般的になりました。

本セッションでは、このようなクラウドネイティブ環境において、抽象データ型をベースとするオブジェクト指向を再定義できないかという観点から考察をしてみます。

型の定義は Open API に代表されるような API スキーマに、カプセル化されたオブジェクトはコンテナに、そしてオブジェクト間のインタラクションは API コールやイベント駆動アーキテクチャを介して行われると考えることができ、言語機能であるかシステムアーキテクチャであるかという違いはあれど、かなり類似性は高いと言えます。

また、このような整理によって、オブジェクト指向のもうひとつの潮流であったメッセージベースの考え方にも焦点を当てることができると考えています。サービスディスカバリによる実装詳細の隠蔽やジョブキューやメッセージブローカーを用いたイベント駆動アーキテクチャはメッセージパッシングに他ならないと考えており、こちらに関しても、オブジェクト指向の考え方を言語機能ではなくシステムアーキテクチャとして捉え直してみます。

このセッションは、伝統的なオブジェクト指向の考え方を知っていて、かつ、クラウドネイティブ技術を使った運用を実践している、あるいは興味を持つエンジニアのみなさんに聞いていただくとともに、一緒に議論や考察を深めていきたいと思います。クラウドネイティブ時代におけるオブジェクト指向の進化とその将来について、一緒に探求しましょう。

オブジェクト指向の父といわれるアラン・ケイは、オブジェクト同士がメッセージを送り合うことによって全体システムが構成されると述べました。しかし、メッセージパッシングとメソッドコールは混同されることも多く、オブジェクトがメッセージを解釈して自律的に振る舞うという本来の意味が忘れられてしまうことも少なくありません。

本セッションでは、自律的に振る舞う車両エージェントとそれによる交通シミュレーションシステムを例にとり、メッセージベースのオブジェクト指向について再度焦点をあてます。各車両エージェントが道路網情報や交通状況に応じて自律的に振る舞い、場合によっては他の車両や交通設備へメッセージを送ることをシステムとして実現しシミュレーションします。

アラン・ケイにとっては（妥協とも言える）実装上の工夫にすぎなかったメソッドという概念が、抽象データ型を中心概念とするオブジェクト指向にとってはそれ自体がオブジェクト間のインタラクションにおける主要概念となっていることについて考察し、そのうえで、メッセージとメソッドの違い、メッセージレシーバーとしてのオブジェクトのあり方についても議論を深めていければと思います。

みなさまはPHPにどのような印象を持っていますでしょうか。
人によってはまともなプログラミング言語として捉えないという方も少くない、毀誉褒貶のとても大きい言語です。

PHPと名のつくものは1994年に生まれ、作者自身のWebについてのニーズに応えるためにその姿を変えてきました。
もとは単なるテンプレートエンジンに毛の生えたようなものでしたが、1998年に公開されたPHP 3.0の頃には現在に近い構文に、オブジェクト指向らしき機能を備えはじめていました。

このトークではPHPの30年近くにわたる歴史の中で、特にOOP関連の仕様に絞って言語の変遷を紹介いたします。
(言語仕様・構文の比較を主な考察対象としており、オブジェクト指向設計については取り扱いません)

本発表では、PharmaXというスタートアップでの２年半にわたるプロダクト開発の実経験を基に、ストーリー仕立てでソフトウェアアーキテクチャの運用についてお話しします。

特にソフトウェアを取り巻く環境や人材の変化に柔軟に対応するための
・ソフトウェアアーキテクチャ定義
・ソフトウェアアーキテクチャ維持・更新機構
・ソフトウェアアーキテクチャ運用指針
の重要性に焦点を当てます。

アウトライン：
〜Ruby on Railsへのレイヤー化アーキテクチャ導入〜
・序章：コアドメインのリアーキテクチャ
・PART１：PMF前のスタートアップでのアーキテクチャ運用
・PART２：束の間の安定期とチーム縮小
・PART３：チーム再編
・PART４：サマリー

発表内容：
序章：コアドメインのリアーキテクチャ
かれこれ2年半前、当時数名のまだ小さなエンジニア組織でRuby on Railsにクリーンアーキテクチャをベースとしたレイヤー化アーキテクチャを導入する意思決定しました。
そんな中、アーキテクチャ設計者が道半ばで退職してしまいます。
残されたメンバーでリアーキテクチャとコアドメインのリプレイスをやり切りましたがここから戦いの日々が始まります、、、

PART１：PMF前のスタートアップでのアーキテクチャ運用
素早い仮説・検証、数々の新規要件の追加により運用課題が噴出しました。
実際の運用課題を例に、ソフトウェアアーキテクチャ定義の重要性についてお話しします。

PART２：束の間の安定期とチーム縮小
運用歴の長いエンジニアが増え、プロダクトがある程度安定化してきます。
アーキテクチャルールの見直しとリファクタリング計画が立ち始め、改善サイクルを回せる目処が立ってきたかに思えました。
そんな矢先、、新規事業立ち上げのためのチーム縮小が起こり、私と新卒エンジニアの２名体制になります。
PART１でのソフトウェアアーキテクチャ定義の重要性に加え、ソフトウェアアーキテクチャ維持・更新機構の重要性について失敗例をもとにお話しします。

PART３：チーム再編
事業が拡大し、チーム再編期を迎えます。
この章ではチームメンバーの入れ替わりを見越したソフトウェアアーキテクチャ運用指針の重要性について実例を元にお話しします。

私たちはオブジェクト指向を使ってユーザーの要求や価値の流れをシステムに落とし込もうとしているが、カントの純粋理性批判的には自分一人による対象の客観視は不可能である。それがイコール、オブジェクト指向を否定するものではなく、絶えずあるべき姿を追求し続けることのみが正しい姿勢で、そのコストを可能な限り減らしていく作業もモデリングに含まれるべきという主張です。

概要

オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。
コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。
これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。

しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。
「clean architecture 達人に学ぶソフトウェアの構造と設計」においても、建築家の建築設計とソフトウェアの設計は同じようなものだと示されています。

そこで、本セッションでは、現実世界に潜むSOLID原則を紹介し、SOLID原則を具象と抽象の両側面から解説します。
具象と抽象の行き来によりOOP初学者の理解を促進することを目的としています。
（人間の脳は具体的で具象的な情報を処理しやすい特性があります。そのため、具象的な例や視覚的な要素が組み込まれた話は、抽象的な概念をより身近で理解しやすいものに変換され、学習効果を高めることができます。この人間の脳の特性を逆手に取ったセッションです！）

私自身、OOPに魅了されてからまだ日が浅いですが、その浅さからくる理解の難しさは未だに鮮明に記憶に残っています。
最新の実体験をもとに、SOLID原則への理解に苦しむ初学者に寄り添い、初学者がより理解しやすいセッションを提供したいと考えています。

想定する聞き手

• SOLID原則をいつどこで何のために使うのかわからないという方
• OOPに興味のある学生・新卒・若手エンジニア

話さないこと

• SOLID原則の厳密な定義や誕生背景
• GoFのデザインパターンやClean Architecture等のOOPの実践的な技法

概要

非デザイナーのWebフロントエンドエンジニアが、「オブジェクト指向UIデザイン──使いやすいソフトウェアの原理」を読んで、OOUIについて考えてみます。
本書籍では、UIデザインにおいてオブジェクト（もの、名詞）を中心に据えるアプローチが、従来のタスク（やること、動詞）指向よりも画面数が減り、作業効率が向上するという「銀の弾丸」的な効果をもたらすとされています。
このセッションでは、書籍中で取り上げられている「ワークアウト(実践演習)」の18の課題に実際に取り組んでみて、オブジェクト指向UIデザインの設計手法がWeb開発のプロセスにおいてどのような効果をもたらすのか、非デザイナー視点での考察をお話したいと思います。

想定する聞き手

・UI/UXデザインの専門家ではないが、ユーザーにとって使いやすいUIを追求したいと考えているエンジニア
・様々な視点から、Web開発の効率化・ユーザビリティ品質の向上のたのアプローチを学びたいと考えているエンジニア
・手を動かしながらOOUIの理論を身につけたいと考えているエンジニア

NestJS という TypeScript で実装を書くことができるバックエンドフレームワークがあります。このフレームワークでは、依存するモジュールをフレームワークのModulesに記述し、依存対象を注入します。

私は、これまで DI を使ったこともなく、使いたい時に new を書いてインスタンスを生成していました。しかし、このフレームワークでは、 new でインスタンスを生成することがほとんどなくなりました。これに伴い、テストも書きやすくなりました。そして、テストを書き始めるきっかけになりました。

このセッションでは、 DI についてと、 DI をするとテストも書きやすくなるということについて話します。

対象者

• テストを書いたことがない方
• DI について知らない方

ドメイン駆動設計において、
ビジネス要件を整理し、設計・開発につなげるには、ユースケース図やドメインモデル図を作成することが多いと思います。
加えて、サービス・プロダクトを継続的に育てていくには、関連するモデリングも一緒に育てていくことが不可欠になります。

今回のセッションでは、チームでのサービス開発において、
モデリング（特にユースケース図、ドメインモデル図）を育てていく際に
考えていることと実践していくうえでの気づきや学びについて、お話していきます。

【内容（予定）】

• 前提・背景について（チームや当初の状態など）
• 育てていく中で気をつけたポイントと考えたこと
• 実践を通して得られた気づき、学びについて
• 今後の課題や挑戦すること

このセッションでは、動物園をモデルにしてクラスとインスタンスを楽しく学べます。難しいことも、身近なものだとわかりやすいですよね。動物クラスから具体的な動物のインスタンスを作成し、オブジェクト指向を学びましょう！

具体的なトーク内容:
オブジェクト指向の基本：クラスとインスタンスの解説！
動物園のインスタンス化：具体的な動物（例：「サバンナのライオン」や「アフリカのゾウ」）をインスタンスとして作成し、それらがクラス定義に基づいてどのように動作するか解説します！

皆さんはオブジェクト指向を学ぶ際、どのプログラミング言語を題材に学びましたか？
C#やJava、Rubyといった「オブジェクト指向言語」を利用するのが一般的ではないでしょうか。ちなみに私もその流れを踏襲したうちの一人であり、クラスとオブジェクト、抽象クラスや継承、カプセル化、ポリモーフィズムという特徴を持った言語を用いたプログラミングこそが「オブジェクト指向」な行為なのだと当時は理解をしていました。

このセッションでは、従来のオブジェクト指向言語とは毛色の異なるGo言語でオブジェクト指向のプログラミングが可能かどうかをテーマとして扱います。

・Go言語はそもそもオブジェクト指向のプログラミングを推奨していないのか？
・伝統的なクラスベースの継承が提供されない言語でどのような実装を考えるべきなのか？

Go言語の哲学を踏まえつつ、従来のオブジェクト指向言語と異なる言語における試行錯誤をセッションとしてお話しさせていただきます。

概要:
多くのエンジニアがオブジェクト指向プログラミングを使用していますが、その核心的な概念であるポリモーフィズムを深く理解し、実践で活用しているでしょうか？このセッションでは、動物を例にポリモーフィズムの実装とメリットを初心者でも楽しくわかりやすく解説します！

具体的なトーク内容:

• ポリモーフィズムの基本的な概念とその重要性を解説！
• 動物で例える継承の解説
• 動物を用いてどのようにオーバーライドするかの解説
• ポリモーフィズムによってコードの再利用性とメンテナンス性がどのように向上するかの説明。
• ポリモーフィズムを活用することで、より効率的で楽しいプログラミングが可能になるというメッセージ。

概要

CSSをうまく扱うための考えとして、オブジェクト指向CSS（OOCSS）という言葉が2009年に提唱され、それに影響を受けた考え方や方法論などが数多く登場しました。それから10年以上経過したいま、そもそもOOCSSはどんな問題を解決すべく登場し、ここ10年でどのような変遷があり、今どのようなアプローチが取られているのかというところを整理していければと思います。

お話する内容

このセッションではCSS設計論に関して「OOCSSが叶えたかったこと」を中心に、現在までのCSS設計のプラクティスを歴史をなぞる形で整理していきます。その上で今現在ではどのような設計論があり、今後どのようなものが登場していくのかというところを私なりにご紹介できればと思います。

話す内容としては以下の内容を考えています。

• OOCSSが登場した背景とOOCSSのオブジェクト指向エッセンス
• OOCSS登場以降に登場した命名規則とCSS設計アプローチ
• CSS in JSとユーティリティファーストのCSS
• 近年使われるようになるであろう@scopeとCSS設計

想定する聞き手と持ち帰ってもらうもの

想定する聞き手としては普段フロントエンド専門とされていない方や、フロントエンド設計をしなければいけないバックエンドなどの別ジャンルのエンジニアの方を想定しています。このセッションを聴くことで「オブジェクト指向の考え方がCSS設計にどのように取り入れられてきたか」という歴史とトレンドを知ってもらい、Webアプリケーション開発での「CSSをどう扱っていくか」を考える手助けの一つとしていただければと思っています。

システム開発の現場では、問題領域（ドメイン）における概念やルールを特徴づけて、モデルとして表現します。
しかし、本当に問題解決に役立つモデルを設計・実装するのは難しく、ドメイン知識をほとんど持たないドメインモデル貧血症と呼ばれる状態に陥っているものや、逆に複数の文脈の知識を持ちすぎて肥大化した Fat Model まで、その実態は様々です。

今回はドメイン・ファーストの考え方でモデルを見直し、それが従来のデータベース中心のモデル設計とどのように異なるかを解説します。
次に、一般的なECサイトのシステムを例に、実際の開発現場で遭遇する具体的なモデルの課題と解決策を探ります。
また、異なる文脈におけるモデルの扱い方や、モジュールの分割、コミュニケーションなど、現場の課題にも焦点を当てます。

わたしは『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』という本を読んで、ドメイン駆動設計（DDD）を学び始めました。
この本について、聞いたことある方や読んだことがある方も多いのではないでしょうか。

このセッションでは、特に新卒エンジニアやDDD初心者の方を対象に、この本の内容を分かりやすく解説し、DDDの基本的な概念から実践的な応用方法までを噛み砕いてご紹介します！！
もちろん、本の内容そのままだけではなく、実際の業務にどのように活かせるか、私の経験から具体的な事例も交えて掘り下げてお話します。

「ドメイン駆動設計って何だろう？」と思っている方も、このセッションを通じて「学び始めてみよう！」と感じていただけるような、入門への最初の一歩を後押ししたいです！

技術的負債や上がらない生産性に悩まされていませんか？
不確実性に強い関数型DDDを実践することで、高い品質と機動力を手にすることができます。

このセッションでは、関数型の旨味を活かしたドメイン駆動開発とそのアーキテクチャを、関数型DDD（fDDD）と称して紹介します。

関数型DDDでは、問題空間を型で適切に捉え、ドメインをより明瞭に表現します。
コンパイル時にビジネスルール違反をチェックしたり、型の抽象化力と合成力でテストを容易にするばかりでなく、決定を遅らせやすくします。

本セッションでは上記の特徴をご紹介しつつ、
　・オブジェクト指向言語で関数型DDDをするには？
　・オブジェクト指向と関数型はどのように共存するのか？
　・関数型のエッセンスは部分的に取り入れているけれど、開発全体でどう活かしていけばいいのか？
といった疑問にお答えします。

こんなトピックをお話する予定です：

・関数型の何がいいのさ？
・オブジェクト指向からみた関数型、やはりオブジェクトファーストな方がDDDしやすい
・関数型DDDとは
・型でドメインを明瞭にする
・型の合成で柔軟に仕様変更する
・関数型アーキテクチャでテストしやすく、開発を進めやすくする
・「決定を遅らせる」を先に作る、プロダクトに適応力をもたらす
・関数型エラーハンドリングで例外ルートをしっかりチェック

（本セッションは、拙著「ContractS Tech Book Vol.1」の「型の力で高品質にドメインをモデリングする〜関数型DDDに向けて〜」の続編に相当するものを予定しています）

多くのエンジニアは日常的にGitを使用していると思いますが、理解して使いこなせているでしょうか？
このトークは、新卒エンジニアやGit初心者を対象に、チーム開発におけるGitの“使いこなし方“に焦点を当て、実践的なノウハウをお届けします！

単にcommit&pushしているだけの「ただ使う」レベルから、わかりやすいPRを作るために適切なコマンドやオプションを選択できる「理解して使う」レベルへとステップアップしましょう！

具体的なトーク内容

• 具体的な実装を用いて、この修正に対してどうコミットすると良いかを解説！
• レビュアーにとってわかりやすいプルリクエストの書き方のポイント！
• 便利なGitコマンド/オプションとその使い所！
• コミットやプルリクエストは今開発するためだけに必要なものじゃない。未来の開発者のために残していくものなんだ。

Gitを使いこなすことは、楽しいプロダクト開発に繋がるということを、皆さんに伝えたいです！