概要）
弊社がOOC2020に出展した際実施したアンケートでは、モデル図を作成していないか、作成してもスケッチにとどまっている方が大半という結果でした。この傾向はいまも変わっていないようです。たしかに、モデル図を描くよりコードを書いて試したほうが手っ取り早い場合もあるでしょう。しかし、実はモデル図を活用したときの旨味に触れたことがないために、スケッチ＋コードが当たり前の方法だと思っている人もいるのではないでしょうか。
また、みなさんの中には、納品物として工程ごとの設計書を求められ、モデル図を作成している方もいるでしょう。そういう方は、モデル図間の整合を図ることや、前工程のモデルの情報をみて、人手で後工程のモデル図に入力するのが煩わしいと感じたことがあるでしょう。
一方で、多くのみなさんは、アプリやテストを書くのにオブジェクト指向プログラミング言語や手厚いフレームワークを使っているはずです。つまり、分析からテストに至るまで、オブジェクト指向の知識と経験なし済ませられるわけではないことも、承知しているわけです。ということは、モデル図には、みなさんがモデル図を活かす方法を手に入れれば、開発の役に立つ余地がまだまだたくさんあるのではないでしょうか。
このセッションでは、上に挙げたような、あまりモデル図が活用できていない方に向けて、モデル図の利用シーンや、モデル図を活用する方法を紹介します。

想定する聞き手）
ほんとうはモデル図を作成した方がいいと思っていながら、実務では作成しなくなってしまった人
開発を依頼したり、保守したりするのに、いまの仕事のやり方ではシステムを俯瞰するのがしんどい人
スケッチとしてのモデル図は作るけど、成果物には残していない人
もうちょっと実装の助けになる設計成果があったらいいなと思う人

話さないこと）
UMLや各図の記法の細かい説明

オブジェクトたちがおしゃべりする世界、それはまるで魔法のようにシステムを動かすことができる力です。
しかし、その裏にはオブジェクトたちの失言や伝言ゲーム、嘘などの罠がたくさん潜んでいます。
良かれと思って導入した非同期処理のQueueやストリーミング処理で失敗はありませんか？

ネット上にある記事を鵜呑みにしてしまうと致命的なアンチパターンに繋がってしまうことも多くあります。
状態をもたせないイベントでマテリアライズドビュー化してしまう、
巨大なランタイムを持たせてしまったハンドラ、
なぜ時系列通りに処理がされなくなってしまうのか、なぜ処理がスタックしてしまうのか、
更新よりも削除が先に動いてしまうのはなぜ？
シリアライズしたオブジェクトが戻せない、副問合せで状態が変わってしまった・・

あの時、どうすればこうした自体を招かずに済んだのでしょうか。
ちょっとしたきっかけでメッセージを使ったシステムを簡単に壊してしまうことがあります。

このセッションでは、ちょっとしたミスやあるきっかけが招くメッセージングのアンチパターンをユーモアたっぷりに解説します。
アンチパターンから抜け出すための時系列とモデリング、
そしてメッセージのルーティングなどいくつかの武器を手に入れましょう！

キーワード：event sourcing、メッセージパッシング、アクターモデル、Queue、分散処理

概要

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

想定する聞き手

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

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

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

CQRS/Event Sourcingは、非機能要件の側面で注目されがちですが、本来はDDDのための設計パターンの一つです。
今回は言語非依存に実装する方法を共有しつつ、一緒に手を動かして理解できるようするハンズオン用セッションです。

想定条件

• コードを書きたい人はPCをご持参ください
• 事前にソースコードとセットアップ手順を共有します。あかじめセットアップし動作確認可能な状態でご参加ください。
• 対象言語でFizzBuzz以上のプログラムが書ける開発者向け
  ※難しいコードは書きません。手本のコードは共有します。
• 参加者はプログラミング言語としてGoもしくはRustの好きな方を選択できます
  ※このセッションを受けると他の言語でも実装できるようになります
• 想定データベースとしてはコマンド側がDynamoDB、クエリ側はMySQL(RDS)
• 実装ではREST API,GraphQLを使うのでその経験があると尚よしです
• 実行環境はローカルのDocker
  ※Dockerを前提していますが、AWS環境にデプロイする前提の構成となります
• 開発環境のOSはmacOSおよびWindows11/WSL2
• ツールはDocker,Git,シェル環境など

コードはある程度土台が提供されますので、そこに新しい機能を追加して理解を深めることになります。

追記(1/31)

当日 解説するソースコードを以下に共有します。
コードやドキュメントはまだFIXしていません。当日まで追加・変更されますが、基本的な設計の考え方は変わりません。

Rust版 https://github.com/j5ik2o/cqrs-es-example-rs
Go版 https://github.com/j5ik2o/cqrs-es-example-go
※Rust版/Go版どちらも実現する機能は変わりません。

追記(3/5)
当日説明する資料をこちら。
https://github.com/j5ik2o/cqrs-es-example/wiki/Introducing_CQRS_ES_System_OOC2024

当日手を動かす方は、開発環境のセットアップ及び上記リポジトリのコードをIDEなどでインポートしビルド可能な状態にしておいてください。

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

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

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

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

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

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

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

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

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

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

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

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

はじめに

• 設計と開発プロセスの関係性
  • システムの構造とタスク構成
  • 設計の影響（生産性、外部品質）
• ソフトウェア設計の知識と技能
  • 経験則　（経験による暗黙知 ⇒言語化：原則、パターン、体験談）
  • 習熟　（手を動かして内面化された経験則）
  • 共創　（知識と技能の連結）

① ソフトウェア設計の基礎知識

a. 基本課題

• 複雑さと発展性
• 大きな泥団子
• 巨大な一枚岩（モノリス）

b. 解決のアプローチ

• 関心の分離→部品化→モジュール化
• 交換容易性（モジュラー性）

c. モジュール化：基本となる４つの技法

• モデル
• 直接的な写像
• カプセル化
• 仕様

② モジュール化

a. モジュールの分類

• 機能(Function)と型(Type)
• インバウンド、アウトバウンド、演算
• 可変と不変
• ブレークダウンとビルドアップ

b. オブジェクト指向プログラミングのモジュール化

• 抽象データ型
• 型の連結
• 型の分類（subtyping）
• 型の階層化？
• 可変から不変へ

c. ドメイン駆動設計のモジュール化

• 事業活動の複雑さ（最適化問題）
• 複雑な業務ロジック
• 分析モデルと設計モデルの一致　（ユビキタス言語）
• アプリケーション固有の型　（値オブジェクト、集約、サービス）

③アプリケーションのモジュール構成（参照モデル）

• コア（中心）
  • 計算判定
  • 業務機能
• ポート（境界）
  • パッシブ（primary)
  • アクティブ(secondary)
• アダプタ（周辺）
  • primary : テスト、Web UI、Web API、バッチ、イベントリスナー
  • secondary : 内部データソース、外部データソース、外部サービス

④モデル駆動設計

• 全体
  • 事業活動、要件、アーキテクチャ
• コア（中央）
  • 業務ロジック、ドメインモデル
  • 業務機能、アプリケーションサービス
• アダプター（周辺）
  • 記録モデル、データベーススキーマ
  • 連係モデル、プロトコル設計
  • 対話モデル、インタラクション設計

クリストファーアレグザンダーの設計についての考察からスタートし、アンクルボブや吉川弘之を引用しながら設計とは本質的に何であるかを解説する。
次に現在主流のAIの教育プロセスと人間の学習プロセスの重要な相違点からAIが得意なこととAIがその原理的にできないことを明らかにする。
これらからAIが本質的には設計はできないということを本セッションで主張したい。
また現在ソフトウェア業界で設計と呼ばれている行為の中にはAIが得意な作業は多く存在している。前述の内容をもとに設計の中でAIをどう活用し、人間は何をすれば効率よう質の高い設計ができるか話していきたい。

暫定アジェンダ

　リファクタリングは設計？
　なぜ設計の本質を考えるか
　設計の語源
　ビジュアルデザインとの分化
　デザイン思考
　ソフトウェアに限定しない設計の全体像

　アレグザンダーの定義
　アレグザンダーの行った実験
　設計の階層性
　ソースコードは設計書か？
　フラクタル
　要求開発
　アーキテクチャ設計
　開発プロセス
　組織設計

　生成AIの仕組み
　人間の学習プロセス
　純粋経験
　設計と純粋経験
　設計行為が行われる際の外部条件
　AIに設計ができない理由

　より良い設計とAIの活用
　ソフトウェア開発において設計が生み出す価値

・レガシーコードにDDDの考え方を取り入れたいけど、どこからどう手をつけたらよいかわからない
・DDDを取り入れてみたが、いろいろな概念や設計パターンがどんな課題を解決するかを理解して上手く適用できているか自信がない

そんなふうに感じたことはありませんか？

今回は、コドモンにおいて、レガシーコードのDDDを取り入れたリファクタリングを、具体的にどのように進めているかをご紹介します。

昨年リファクタリングをしつつ機能改修を行った際の生々しい実例を通して、DDDの設計パターンを取り入れようとしてつまづいたこと、そして、その結果として得られた学びを共有したいと思います。

レガシーコードに立ち向かいながら「より良い設計」を目指すみなさまにとって、少しでも参考になれば幸いです。

概要

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

お話する内容

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

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

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

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

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

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

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

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

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

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

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

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

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

レバテックは現在、フリーランス・派遣・就転職、新卒の各領域を軸に様々なサービス・事業を展開しています。

これらシステムで共通となるルールがいくつか存在しています。
例えば、「メールアドレス」「電話番号」「生年月日」などのValidationであったり、振る舞いに関するルールです。

レバテックではこれらのルールを各システムが保持しており、ルールの分散とルールの不一致により、何件ものシステム障害を起こしていました。
このシステム障害の原因として、ルールの分散とルールの不一致もあるが、共通ルールが存在しておらず、どのルールが正なのかもわからず、システム障害を恒久的に防ぐことが難しくなっていました。

そこで、レバテックにおける共通ドメインライブラリとしてドメインオブジェクトや値オブジェクトを管理するライブラリを作成し、共通ルールをライブラリとして実現しました。
このライブラリはNPMのプライベートパッケージとして作成し、TypeScriptで記述されたドキュメント生成ツールであるtypedocを活用して、社内共通ルールを一元管理できるようにしたものです。

これにより障害発生を大きく削減することができ、また、今まで暗黙知になっていた共通ルールもこのライブラリにどんどん実装され、たくさんのドメイン知識を貯めることができました。
本セッションではこのライブラリ作成に至った経緯、ライブラリの概要、現在の活用状況、今後の活用についてお話しさせていただきます。

オブジェクト指向は大切、オブジェクト指向は難しいなどと言われますが、ではオブジェクト指向とはなんでしょうか？実際のところ、広く合意のあるような定義は見当たりません。
ただ、ここではこれからの開発作業をよりよいものにするための話をするべきなので「オブジェクト指向がきっかけだったのだから全部オブジェクト指向だ！」のような過去の栄光のような話をしてもあまり意味はありません。
そこでこのセッションでは、関数型など他のアプローチでも可能なことをオブジェクト指向から分離させていき、そうするとオブジェクト指向として何が残るのか、またそのような中で、今までばくぜんとオブジェクト指向として話されたことをどのように整理して扱うといいのかをお話しします。
内容はWEB+DB PRESS vol.132 「オブジェクト指向神話からの脱却」を発展させたものになる予定です。
https://gihyo.jp/magazine/wdpress/archive/2023/vol132

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

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

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

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

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

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

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

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

今回は EC サイトのシステムを題材に、実際の開発現場で遭遇する具体的な課題について考察していきます。
そして生成 AI を活用してコードを書くことを前提に、開発を進める過程で陥りがちな戦術的プログラミングを紹介します。

最後にドメイン・ファーストの考え方で設計を見直し、どのような変化があるのかを説明します。

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

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

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

オブジェクト指向プログラミングは、コードの組織と再利用を促進するための強力な方法論ですが、そのコードの可読性に関するベストプラクティスやテクニックには多くの意見があります。
このラウンドテーブルセッションでは、参加者がオブジェクト指向プログラミングのコードの可読性に関する実践的な知見を共有し、意見を出し合います。
集まった意見や知識を通じて、より良いコードの可読性を追求するための方法やテクニックを議論し、深める機会とします。

参加者は、実際の経験や困難なケースに基づいて、OOPの可読性向上のためのヒントの提供が期待されます。
これにより、すべての参加者が具体的で実践的な知識を得ることができます。

【概要】

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で開発すると、どのようなメリットがあったか、開発時にどういう所で悩んだのかなど、参考としていただければと思います。