
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
リンクをコピー
記事をブックマーク
大嶋勇樹氏:ということで、ここまでビジネスロジックの実装について話してきました。ここからは最後のステップとして、「Controllerに全部書く」からどうやってステップアップするかを話していこうと思います。
ここまでで質問があれば、ぜひQ&Aにもらえれば回答します。せっかくなので、このタイミングで「ドメインモデルパターンはドメイン駆動設計と同義ですか?」(という質問)に回答しておこうと思います。
ドメイン駆動設計はドメインモデルパターンを使いますが、ドメインモデルパターンを使ったからといってドメイン駆動設計ではないという関係だと私は認識しています。こういう質問が来た時のために、私の横にホワイトボードを用意していたので、そちらを使って解説できればと思います。
せっかくなので、ドメイン駆動設計と今日話しているドメインモデルパターンの関係を話そうと思います。
(ホワイトボードに書きながら)これも人これも理解の仕方が違うところが大きいですが、ドメイン駆動設計は大きく要素が2つあります。1個は戦略的設計というもので、もう1個は戦術的設計です。DDDの本を読んでいても、こういう言葉、こういう分類みたいな感じでいろいろ話されます。
この中で、今日はレイヤー化で3層にするとか、レイヤードアーキテクチャで4層にするという話をしましたが、そういう「レイヤー化はどうする」みたいな話も戦術的設計の一部として出てきます。あとは、ドメインモデルを具体的にどう実装するべきかみたいな話も出てきます。
ただ、ドメインモデルパターンを使えばDDDということではないし、DDDはドメインモデルパターンを使うことを想定した設計のプラクティスではありますが、イコールではないというところですね。
より大事なのは、戦術的設計、実装方式に注目してDDDと呼んでいる例がけっこうあります。戦術的設計だけやっているのは軽量DDDと言われて、場合によってはアンチパターンとも言われます。
個人的には、それでもやってもいいと思うし、別にそれ自体(だけで)もやる価値はあると思うのですが、戦術的設計だけをやるのはあまり良くないよと言われることもあります。
DDDの中で私の理解がすごく大事なのは、戦術的設計も大事ですが、それ以上に戦略的設計と言われるところです。1個はDDDの思想というか、考え方みたいなものです。
DDDはドメイン駆動設計の略ですが、ユビキタス言語を使ってドメインエキスパートと話してドメインモデルを整理していこうとか、そういった「実装上どうだ」だけではなくて、ドメインエキスパートという領域にすごく詳しい人とユビキタス言語、共通言語を使ってちゃんと認識合わせしましょうとか。
その認識合わせをして出来上がったモデルを、そのままコードに落としましょう。それができるように、ちゃんとドメインモデルを隔離したレイヤー化をしましょうという話です。
特にDDDっぽくちゃんとやってるとなると、コードの実装だけじゃなくて、「ドメインエキスパートとの話をちゃんと聞いていますか?」とか「ユビキタス言語と言いますが、そういう言葉の使い方をしていますか?」とか。そちらのほうがむしろ主眼かなと思っています。
あとはサブドメインみたいな言葉や境界づけられたコンテキストが出てきますが、システムでいえばシステムのどこで分割するべきかにも関係してくるような要素も出てきます。
このあたりを全体的に含めてDDDだと私は思っているというか、そういう理解の人もある程度いるはずです。なので、ドメインモデルパターンをやっていたらDDDではなくて、DDDの重要な要素の1つにすぎないという感じです。
逆に、戦術的設計だけやっているのはDDD的にはあまり良くないとされることもある関係です、ということで質問に回答しました。
ちょっと画面共有に戻って最後の話をしていければと思います。質問があれば、どんどんQ&Aにもらえれば、適宜回答します。
ということで、「Controllerに全部書く」からのステップアップを話していこうと思います。
ここまでいろいろ実装の仕方を見てきましたが、具体的に今あるコードを「自分がわりとControllerにいろいろ書いているな」という状態から、どうやってステップアップしていけばいいのかみたいなところを話していこうと思います。
例えばノンフレームワーク、フレームワークを使わなかったり、Node.jsのExpressなどの軽量なフレームワークを使ったりしていて、ControllerにSQLまで書かれている例を考えてみようと思います。最近はORマッパーを使うので、SQLが書かれていることはあまりないかもしれません。
(スライドを示して)例えばControllerにSQLが書かれている(場合)というのは、こんな構成になるわけですね。プレゼンテーション層、ビジネスロジック層、データアクセス層にまたがってControllerがあります。
利用者とやりとりするのもControllerの役割だし、ユースケースの実現とドメインロジックというビジネスロジックのいろいろな要素がControllerの役割だし、データベースでやりとりするSQLも書かれています。
一応データベースと一致する、データベースのテーブルと合わせたデータの入れ物クラス。Entityと言うこともありますが、なんとかRecordみたいなクラスやEntityと言うこともありますがあとUIは、テンプレートエンジンを使っていて、一応分離されている構成も見なくはないですね。この場合、あまり意識してやっているわけではないと思いますが、こういうコードも見かけることはあり得ます。
ここからどう整理していくかはいろいろあるとは思いますが、例えばまずデータアクセス用のクラスを設けてみます。一例として、データベースと1対1で対応するGatewayみたいなものや、なんとかGateway、Player Gatewayみたいなものを設けてみてもいいと思います。
でもこれはControllerの役割が多すぎるんですね。利用者とのやりとりもそうだし、ユースケース、ドメインロジックもそう。
(このように)Controllerの役割が多すぎるので、例えばServiceクラスを設けてみます。プレゼンテーション層とビジネスロジック層をしっかり分離するわけですね。Serviceクラスには、ユースケースとドメインロジックを持たせます。
こうなってくると一応整理されている、よく見るコードになってきているイメージです。この間にDTOとかなにかは多少いるかもしれませんが、ざっくり、ControllerとServiceとデータアクセス用のなんとかGateway、Gatewayの名前はいろいろありますが、こういう構成はわりと見かけます。
ただ、この構成はServiceの役割が多すぎます。そして、複数サービスで似たドメインロジックを実装したい時に、コードが重複しやすいです。似たというか、まったく同じドメインロジックを実装したい時に、重複すべきではないドメインロジックがサービス間で重複しやすい構成だったりします。
そこでドメインロジックをModelに持たせると、Serviceの見通しが良くなりやすいです。Serviceがユースケースもドメインロジックも持っていると、Serviceのメソッドが100行とかにもぜんぜんなるし、普通に30行、50行とかになって見通しが悪くなっていきます。
結局はドメインロジックの設計次第なところもありますが、ドメインロジックをドメインモデルにしっかり持たせて、そこをしっかり整理していけば、ある程度コードも見通しが良くなっていくかなと思います。
(スライドを示して)さらに加えて、これはビジネスロジック層と書いてありますが、ドメイン層をアプリケーション層、ドメイン層と分けたり、Repositoryパターンを導入したりということも考えられるとは思います。そうすると、まさに途中で説明したようなアーキテクチャになっていくイメージですね。
ここでのポイントは、クラスごとの役割分担だと思います。難しい表現はいろいろありますが、役割分担はけっこうわかりやすい言い方かなと個人的に思っていて、クラスごとにどんな役割を持たせるかがすごく大事だと思います。
これでは1個1個のクラスの役割が、「このクラスの役割は何ですか?」「このクラスは、テーブルと一致するデータの入れ物です」「このクラスの役割は、ユースケースです」と、一言で説明したりがすごくしやすいと思います。
こういう役割分担がすごく重要だと思います。ここに出している役割はあくまで例であって、例えばこれ以外にも表示用の変換が必要な場合がよくあると思います。
その表示用の変換は、どこかの既存のクラスに入れてしまうこともあるし、「Presenterというクラスを作って、そこに書きましょう」とすることもよくあります。こんなやり方が1つあると思います。
(次回に続く)
関連タグ:
“1つの独立して動く要素”の内部を整理し直す 「改めて整理するアプリケーション設計の基本」で伝えたいこと
アプリケーションアーキテクチャ理解に必要な“3層構造” プレゼンテーション層・ビジネスロジック層・データアクセス層それぞれの役割
3層アーキテクチャで最も謎な「ビジネスロジック層」 “システムのコア”をゲーム「リバーシ」で解説
「ビジネスロジックの処理は2つに分類すると整理しやすい」 4つの例から考える、プレゼンテーション層・データアクセス層の見分け方
ビジネスロジック層内部の2つの実装パターンを比較 選択時に考えたい、アプリケーション設計の観点
「クラスごとの役割を明確化すること」がポイント アプリケーション設計におけるドメインロジックの分離法
重要なのは「基本を押さえ、適したものを採用すること」 “本来の役割”を押さえたアプリケーション設計
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
第20回エクゼクティブメンターイベント「今、「ひと」と組織が共創する〜働き方の未来へ」
2024.12.07 - 2024.12.07