筆者は現職の（株）タイミーも含め、数社のスタートアップでサービスの開発に従事してきました。
オブジェクト指向を学び、ドメインをどう抽象化するか考え、実際にコードを書き、同僚とともに知恵を出し合った末に一つの結論にたどり着くのです。

「このコード設計よくないね」

しかし負債を返すためのリファクタリングに当てられる工数は限られています。本当は何日でも設計について悩めるのに数時間で結論を出さなくてはならず、手癖で設計するしかないような現場もあることでしょう。
いい設計はわからないが、痛い目に遭った設計はわかる。そんな自分の経験と設計原則を照らし合わせて一体どうすればよかったのかを検討していきます。

そしてタイミーで辿り着いたよりよい設計のためのプラクティスについてもご紹介いたします。

オブジェクト指向におけるインターフェースという概念は，アプリケーションやライブラリの実装に欠かせない要素です．しかし，その抽象的な性質から，初めて触れる人にとっては活用方法がイメージしにくいこともあるかもしれません．

本セッションでは，そんなインターフェースを次の３つのカテゴリーに分類してみます:

【レイヤー分離】
アプリケーションの異なるレイヤー間での依存度を下げることで，変更が他の部分に及ぼす影響を局所化し，システム全体の安定性を保つ．

【特性表現】
オブジェクトが持つ特定の「振る舞い」や「能力」にフォーカスし，その表現力を高めることで，オブジェクトの再利用性と明確性を向上させる．

【差替可能性】
異なる実装を容易に切り替えられるようにロジックを抽象化し，それによってシステムの柔軟性と拡張性を高める．

「インターフェース」と一口に言っても，その使い方は多岐にわたります．
具体的な実装例を交えて，それぞれのカテゴリーがどのような場面でどのように活用されるのかを詳しく掘り下げていきます．

「良い景気をつくろう。」のミッションの下、経営管理SaaSを開発・提供するログラスでは、創業初期からドメイン駆動設計（DDD）を使ってソフトウェアの複雑さに対応して参りました。しかしデータについてはそうとも言い切れません。
ログラスでは関数型DDD等、従来の開発をアップデートするための取り組みを進めています。そのなかで今回は、急激に増加するデータや分析ニーズの高度化に伴いログラスがどのように戦ってきたかをお話します。

キーワード：アジャイル多次元データモデリング、クエリパフォーマンス、関数型データエンジニアリング

弊社がドメイン駆動設計（DDD）を取り入れて開発がどのように変化してきたのかをご紹介しようと思います。

弊社では設計と実装ともに良い形で導入できていると考えています。

とは言え最初から上手くできていた訳ではなく、
ドメイン駆動設計という設計思想を取り入れる事で開発組織自体が変化してきた結果現在があります。

DDDはたったひとつの冴えたやり方が有るわけではなく、プラクティスの集合体と考え日々より良い形を模索しています。
そういった中でこういうことは効果があった、なかったと言う事も交えながらお話させて頂こうと思います。

ドメイン駆動設計に限らず、長期的な開発に向き合う皆さんの参考になれば幸いです。

オージス総研で現場の最前線に立つ3名がそれぞれの役割において現場に役立つ本（オブジェクト指向あたりに関連する本）が、どのような課題や問題で役に立ったのか、その一部を熱く語るセッションです（一人1冊の想定。計3冊くらい）。
同じような課題・問題にある方の問題解決に役立ち、学びに役立つ本に出合えるきっかけになれば良いと思っています。
その本を選ぶかどうかは分かりませんが、オージス総研ではオブジェクト指向に関わる本の出版に関わらせていただいています。当日のスポンサーブースには本を何冊か広げて展示しておくので、皆さん、ブースに来て手に取ってみてください（販売はしてません。悪しからず）。

開発のゴタゴタの原因は、結局は人間関係の問題。
人間関係をうまく行かせるためには、コミュニケーションの成立が重要です。

皆さん、UML（統一モデリング言語）は、言葉だってこと気づいてますか？
言葉は、伝えたいことを伝えるコミュニケーションツールです。

モデリング言語は、言葉としてより緻密に設計されているので、
日本語で話すように伝えられれば、開発のゴタゴタも解消！！ するかも！？

★★UMLは面倒くさいと思っている人に、朗報です★★

2019年M1グランプリ王者の代表作のネタ「コーンフレーク」をベースに、
モデリング言語での会話のスムーズさとUMTPの良さをお伝えします。

...いや いや、UMLでしゃべるだけだから、、、。

2034年には、小学生がUMLで日記を書く時代がくる！！...かも！？

このセッションでは、現代のソフトウェア開発においてオブジェクト指向プログラミング（OOP）を使うことによる課題と、
SOLID原則やKISS原則などのシンプルな原則を用いて多くの開発者が経験するOOPの複雑さと「ファットクラス」の問題から始めます。

最終的に、関数型プログラミングのエッセンスを取り込むことで、OOPにおけるこれらの原則を補完し、マルチパラダイムのアプローチを実現する方法を示します。
また、C#を用いた具体的な例を通じて、この統合されたアプローチが実際にどのように機能するかを示します。

このセッションは、開発者がより良い設計決定を下し、保守性と拡張性に優れたソフトウェアを作成するための考え方を提供することを目指しています。
参加者の皆様が、原則に基づくコーディングによって、ソフトウェア開発の新たな可能性を探求する一助になれば幸いです。

【概要】

SaaS型Webサービス「カオナビ」開発では、PHP/Laravelフレームワークを利用しています。
モノリシックなシステムになってしまい技術負債が高い状態になっています。

機能開発と並行しながらでも、技術負債を増やさないため、減らしていくために、Package by Featureでの開発スタイルが選択できるようになりました。Package by Featureを取り入れたチーム開発での悩みや、成果などを、ありのままに開発者視点で紹介します。

【主なトピック】

• Package by Featureとは
• チームにPackage by Featureを取り入れた背景
• Package by Featureを取り入れた開発での悩み
• Package by Featureを取り入れた開発の成果
• 今後の方針

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

想定する聞き手としては、バックエンドエンジニアの方を想定しています。
このセッションを聞くことで、Package by Featureで開発すると、どのようなメリットがあったか、開発時にどういう所で悩んだのかなど、参考としていただければと思います。