00:05
はい、みなさんこんにちは。kkeethこと桑原です。本日もやっていきましょう。kkeethのエンジニア雑談チャンネルです。
この番組ではウェブ業界に関することやエンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
で、今日は、昨日もちょっとオブジェクト思考プログラミングのOOPのお話をしてたんですけど、
そのまま、現代のオブジェクト思考プログラミングの中で一番有名だというか、主流となっている手法がDDDであると思っております。
このDDDを、よく話は聞くし、いろんな本も出てたりするので、だいぶ情報とかが出回っていますし、
開発現場でもDDDは割と導入されているんであろうと思っておりますが、僕自身は全然やったことがないし、
特にフロントエンドエンジニアとして仕事することが最近はもっと多かったので、
そんな需要がなかったと言ったらそれまでなんですけど、ニーズがなかったのでDDDに残しててやってこなかったので、
これを機にね、学んでみたくなったというので、どうやって学ぼうかと思ったんですけど、
まあ現代の流れでは、とりあえずAI君と学ぶことが良さそうだなっていうので、まずはAI君に聞いてみたっていうのが今日のお話です。
いつも通りな感じですけど、もう最近とは言わなくAIに聞きながら学習するっていうフローが僕の中で確立してしまっているので、
正しいこと言ってるとは限らないし、ちゃんとしたことはしっかり書籍で学ぶ方がいいとは思ってますけど、
入門としてどんな感じだっていう概要を掴むぐらいだったらいいのかなっていうので、
聞いてみたので早速どんな回答が来たかっていうのを紹介していきたいと思います。
DDDとはっていうお話ですね。
一番最初にDDDのなり方をしたんですけど、
DDDが結局よくわからないので、わかりやすくまとめて何なら過剰書きで教えてくれっていうふうに聞いてみたんですね。
ではそれの回答ですけども、ドメイン駆動設計、ドメイントリブンデザイン、DDDですね。
というものはソフトウェア開発における複雑な要件とビジネスロジックを扱うためのアプローチになりますと。
以下の過剰書きでDDDの主要なコンセプトをわかりやすくちょっとまとめてみました。
合計ですね、7個にまとまってますね。
はい、ちょっと長いですけども。
1つ目はまずドメインモデルの中心化と書いてますね。
DDDっていうのはビジネスの専門知識、いわゆるドメインですね。
っていうものをソフトウェアの中心において、その知識をモデル化することに重点を置いてますと。
名もドメインモデルってじゃあなんぞやっていくんですけど、いわゆるビジネスのルールとか操作っていうものを表す抽象化したようなモデルですよと言ってます。
いきなりモデルってワード出てきたんですけど、そもそもじゃあモデル化ってなんぞやって話をちょっと聞いてみたんですね。
モデル化っていうのは実世界のシステムとかプロセスっていうものを理解して、その特徴や動作っていうのを抽象化してシンプルな形で表現するプロセスですよ。
これは特にソフトウェア開発やシステム設計において重要な役割を果たしています。
モデル化を行うことで以下のような成果物や利点が得られますよというところで。
03:00
1つ目はまず抽象的な表現ですね。
実世界の複雑なシステムとかプロセスっていうのをより扱いやすい形式で表現をします。
これには図であったりとか数学的モデルだったりとか、コード内のクラスとかオブジェクトなども一応含まれます。
そんな形でもできます。
あとは図やダイアグラムってとこですけど、いわゆるUMLですね。統一モデリング言語って言われるもの。
UML使ったそのUML図だったりその他のビジュアル表現を作成することが一般的になります。
これにはクラス図とかシーケンス図、状態図などみたいなものも含まれています。
いろんな図とかダイアグラムが作られます。
あとはドキュメントですね。
プロセスやシステムの動作、ルールとか制約を記述した文書とか。
これは開発CMやスティックホルダー間でのコミュニケーションを助けるみたいなものも作られます。
ラストはやはりコードですね。ソフトウェアのコードです。
クラス、メソッド、ましくは関数の形で実装されたモデルと。
これによってモデル化されたシステムとかプロセスが実際のソフトウェアとしても動作をするというところで。
モデル化はそんな感じで、いろんなものを具体化、具体化、もしくは言語化をするといったところですね。
モデル化するときの、ちなみにプロセスっていうのもありまして、どんな風なプロセスで行うのかって話が一応書かれてました。
一つ目はまず要件の識別からですね。
システムが満たすべき要件とか機能をまず明確にしましょう。
次はドメイン分析となることですね。
対象となるドメイン、いわゆる分野とか業界知識とかあります。
その特徴や規則っていうのを理解していって、どこまで来たら次に抽象化をしますと。
複雑な要素っていうのを基本的な概念に分解をして、重要な要素に焦点を当てましょうと。
抽象化が終わったら次の関係性の定義ですね。
システム内の異なる要素間の関係っていうのを定義をしていきます。
最後は振る舞いのモデル化ですね。
システムがどのように動作をするかっていうのを表すルールとかロジックまで定義していく。
こんな感じでモデル化のプロセスを行っていけばよいんじゃないのという話ですね。
あとはモデル化の利点みたいな話も書かれてますけど、これは皆さんわかっているというか、
なんとなく肌で感じているところはあると思うんで、そこは省略しますね。
では戻りまして、DDDのコンセプトの話に戻りますけど、
最初はドメインモデルの中心化をしたと。
次は指き足す言語っていうところですね。
開発者とビジネスステークホルダー間で共通の言語、指き足す言語を使用しますと。
この言語はドメインモデルを表現し、誤解を避けるために使われますと。
まあでも作られるとかアウトプットするものに応じて、それぞれの言語を使うと思いますので。
なんか統一的ななんかみたいな感じではないと思う。
だから指き足す言語みたいなワードを使ったのかなって思ったりはしました。
続いては境界づけられたコンテキスト。
これ何かっていうと、システムを複数のコンテキスト、サブシステムとかモジュールとかに分割をしましょうと。
で各コンテキストっていうのは独自のドメインモデルと指き足す言語を持ちますというところですね。
とにかくモジュール分割していきましょうという話でした。
で続いてはエンティティと値オブジェクトですね。
ここら辺まるくなんかコアなコンセプトの話ですけど。
エンティティとは識別詞によって区別されるオブジェクトのことで、時間とともに属性が変化することがあります。
06:02
例えば顧客とか注文みたいなところがエンティティだというふうに定義します。
でそれに紐づく値オブジェクトと呼ばれるものですけど、英語は確かvalueオブジェクトだった気がします。
値オブジェクトっていうのは属性の値によって定義をされて、不変性を持つオブジェクトのことを言いますと。
先ほどのお話でいくと、例えば金額とかもしくは住所とかっていうものですね。
住所はさすがに不変性を持つかと言われると、引っ越しされたりするので住所は変わる可能性はもちろんありますけど、そんなにでかく変わるわけではないという意味では値オブジェクトと言ってもいいでしょう。
金額も変わる可能性はもちろんゼロではないんですけど、一旦決めたらそんなにプロダクトの値段を変えることはないと思います。
その意味では値オブジェクトとしてもいいかもしれないですね。
っていうところでした。エンティティと値オブジェクトですね。
続いて集約のお話ですけど、集約っていうのは一連のオブジェクトをカプセル化をして統一された単位として扱うことでモデルの整合性を保ちます。
その各集約したものっていうのは集約ルート、通常はエンティティを通じてのみアクセスすることができます。
日本語に訳されているから難しいので、この辺はもしかしたら英語のままの方が良かったかもしれないですけど。
リポジトリとサービスっていう概念ですね。
リポジトリというのは集約の永続化と再構成を担当してくれます。
カプセル化したものの永続化と再構成、再カプセル化を担当してくれるのがリポジトリです。
で、続いてサービスですけど、サービスとはドメインモデルの一部で特定のビジネスロジックをカプセル化したものと言います。
リポジトリと結構被るイメージはありますけど、やってることは似てるが目的とか背景にあるものが違うということですね。
続いてドメインイベントと言われるもの。
こちらはシステム内の重要なビジネスイベントを表し、他の部分に影響を与える可能性があるよと。
あとは細々書いてあるものがあって、アーキテクチャのレイヤー分けの話が入ってますね。
システムをレイヤーに分けましょうと、それぞれの責任を明確にします。
例えばプレゼンテーション層とかアプリケーション層、ドメイン層、インフラ層に分けてそれぞれの責務っていうのを明確にしましょうと。
なんかあれですね、OSI参照モデルに近いような話をしてますけど、まあまあその辺でしょうね。
この分離によってコードの再利用性と保守性というのも向上しますよと。
さっきのメインティティとか対オブジェクトの端もそうですけど、カプセル化モデリングもやっぱりしていくのでそこで分離してますけど、
レイヤーでも分けてより保守性とか再利用性をちゃんと担保するって言われてますね。
なんかより設計の端を本当にするんですね。
続いては戦略的な設計の話ですけど、
大規模なシステムにおいてDDDってのは複数のチームが異なるサブドメインに集中できるように戦略的な設計を提供します。
これによって各チームはそのサブドメインに特化をして効率的に機能配置を進めることができる。
ああ、なるほどですね。
責務とかドメインをしっかり分けて、それぞれのチームがそれぞれのドメインを担当して、最後がちゃんとやるような感じにできると。
ただ、レイヤー分けたりモデルに分けたりとかはしてはいますが、最後の結合のところがしっかりここが肝になる気がしますね。
09:04
よくある結合屋さんがいなくなったら割と大変みたいな話が出てきそうな気がしたので。
そこなんですかね、いけるものなのかな。
はいはい、そういう設計の方法です。
あとは継続的な学習と改善も必要だと言っていて、
DDDっていうのはドメインモデルを継続的に改善もしてビジネスの変化に対応するプロセスっていうのも重視をすると。
これらの原則と実践によってDDDっていうのは複雑なビジネス要件とロジックを効果的に管理して、開発チームとビジネステークホルダー間のコミュニケーションを促進したりします。
またシステムの拡張性と補正効果をさせればできるよというので。
難しいというか、書籍になるぐらいなので、複雑かつ深みがある分野ではあるんだろうなと思いますけど、
まあ今はちょっと抽象的に軽く概念のお話だけさらっと流しているので、
やっぱり何か分かったよね、分かんないな。
難しそうですね、はい。
なるほどでした。
まあでもDDDの一旦どんな概念かイメージはなんとなくできましたし、
確かにこれはオブジェクト思考プログラミングの文脈で語られるとそうだなという感じがしました。
思いっきり設計の味ですからね。
はい。
DDTの学び方とかロードマップがありますかみたいなのもついでに聞いてみましたと。
一応DDTはすごく概念が多岐に渡るので、段階的に学習を進めることが重要だというので提案をいただきましたね。
初心者向けと中級者向けと上級者向けだと3段階に分けて学ぶのいいんじゃないのって提案をいただいて、
初心者向けにはまず基礎と理論の理解から入っていけと。
先ほど言ったようなDDTの基本原則の学習ですね。
核となるコアな概念であるエビキタス言語とか、先ほどの境界づけられたコンテキスト、エンティティと値オブジェクト集約っていう先ほどのやつをまずは理解しましょう。
あとは基本文献の読解をするのもいいんじゃないと、書籍なりでやっぱりまずは基礎にしっかりやりましょうと。
はい、エヴァンズの有名なドメイン駆動設計の書籍を読むと。
そんな感じですね。
あとはオンラインコースがチュートリアルのためにとにかくまず基本の概念を徹底的にまだ学びましょうってところからですね。
設計の話をするのでしっかり基本が大事だよねっていうところはやはり変わらないと。
続いて実践と応用というところでモデリング技術の実践ですね。
実際のプロジェクトでもドメインモデリングとまず行って概念をそのまま適用しましょうと。
これできればやったことある方とか先輩がいるんであればですね、その人と混ざってもらってやるのがいいかもしれないです。
もしくはコミュニティとかワークショップとかもあったりはするのでそこに参加しましょう。
もしくはミートアップも全然やられたりするので知識も深めていったり経験を共有すると。
で、あとは3つ目ケーススタディの分析ですね。
成功したDDDプロジェクトのケーススタディというのがもし公開されてたりするのであればそれを見ながらどのように概念が適用されたのかっていうのを理解していきましょう。
成功事例を見るって確かに一つの良い学び方かもしれないですね。
はい、というのでまずは基礎を学んで次は実践をしてみましょうっていう話ですね。
最後上級者向けですけどそこに深みとリーダーシップっていうお話が出てきました。
複雑なドメインへの応用ですね。
1回はやりましたっていうところでそのどんどんどんどん深めるって意味ではより複雑なビジネスドメインのお話に対してもDDTの適用を試みていわゆる筋トレをしましょうみたいなところですね。
12:06
はい、で2つ目としてドメイン駆動設計の指導ですね。
他の人に教えるっていうので開発者のいいですしチームに対してもDDTの概念とか実践を教えると。
まあ教えることが一番の学びになりますからこれもそうですね。
最後継続的な学習とアップデートというところで最新トレンドもそうですし新しい情報のキャッチアップとかアプローチっていうのを学び続けましょうというところですね。
以上やはり合同みたいなものはないというので他のプログラミング言語もそうですし技術とかもそうですけど同じ感じでしたね。
まあDDTは今もやっぱり進化をし続けている分野であることも間違いはないので最新の情報をいわけるのも大事ですし実際に他の人たちがどういうふうにやってるとかそういう知見とかっていうのを学びに行くためにもいろんな勉強会であったりとか。
コミュニティーのところに関わっていくのも一つかなというところですね。
まあ設計に本当に王道はないと思いますし今は主流になっているだけでありますけどこれがまあ数年後変わることなんて大いにあり得るとは思っているので今どんなふうな使い方をしていますかっていうそのユースケースを学びに行くという意味でどんどんコミュニティーに入っていくのが良いなと感じました。
まあでもやっぱり僕はまずやってもいないのでコードを書いてみるのもそうですけどまずはそのドメインモデルに落とし込むっていう当たり前なんですけどスタートからやってないのでそこからまずも僕はやっていきたいな。
と思いましたねはいあとドメイクの設計だとあれですねナルセさんの書かれた小説もあったりするのでそれを読むのもいいかもしれないですねはいっていうところでごめんなさい今日はすごくふわっと抽象的なお話でしかなくてですね表面をなめただけなんですけど結局よくわからんかったのでなんだかんだちゃんと学ぶのが一番いいなと思いましたはい今回はこんなところで終わっていきたいと思います
いつも聞いてくださり本当にありがとうございますではまた次回の主力でお会いしましょう
ばいばーい
