【DDD】ドメイン駆動開発のメリットと始め方 codezineを読んでみる

codezine.jp

2ページまでよんだ。DDDってなんのために使うんだっけー？という話

DDDにおける2つの設計

戦略的設計と戦術的設計

whatとhowみたいな感じだな

戦略的: 何を設計し実装するのか
戦術的: どのように設計し実装するのか

「戦略的設計」を実施せず、エンジニアが取り組みやすい「戦術的設計」にだけ注力すると、「軽量DDD」と呼ばれる事業価値を発揮できない貧弱なDDDになってしまう

気をつけよ。ちゃんと要件を確認してモデリングしてからやりましょってことね

DDDの概略

DDDは「高品質」のソフトウェアを設計する手法です。ここでの高品質はバグのないという意味ではなく、ビジネス的にも成功していることを指します顧客と開発者が共通言語(ユビキタス言語)で会話して、一体感あるチームとして、事業価値の高いソフトウェアを開発する手法

んーわかる。運用者と開発者、顧客が同じ単語で話すの大事

DDDのメリット

プログラマとドメインエキスパート(業務に最も詳しい人)が共通言語で話していくことで顧客が開発するようにソフトウェアを作ることができる

ドメインエキスパートすら詳しくない業務を深く検討することでチーム内に業務知識が広まる

コードがドメインの設計を表すため翻訳が不要になる

DDDの戦略的設計を行うことは、開発費用をコストではなく事業を伸ばすための投資に転換できる。

fmfm. 確かに業務について深く考えることでビジネスにおけるコア要件の確定や不足箇所を洗い出すことができるよなー

ちゃんと要件相談して決めてから作ろうなっていう当たり前のことを言ってるんだけど、要件定義って時間かかるしここのコスト値切ろうとするのはわかるなーと。

値切った代償が大体、技術的負債になると思うしちゃんとやろうという戒め

複雑さへの対処

ソフトウェア開発の難しさは対象領域の「複雑さ」からくる。この複雑さと戦うために「ドメインモデル」を用いる

多くのプログラマは業務処理をそのままの手順で記述した「トランザクションスクリプト」を書く。

DDDでは業務をオブジェクトの振る舞いとして表現するドメインモデルとして実装する。これによってビジネスロジックが適切な場所で一元管理される。

手続きを羅列するんじゃなくて、個々の役割をうまく果たすオブジェクトが協調しあって事を成すように作っていく。

個々の役割がドメインモデルで表現される と考えてこの先を読んでいこう。