ソフトウェア開発メモ

日々のソフトウェア設計、実装で考えている、気づいた事を書いています。それが真実か否かは保証しません。悪しからず。

ドメイン駆動設計

依存、シングルトン、隠れインスタンス変数

メソッド中でインスタンス変数が毎回生成される形で関わりあいを持つクラスは関連ではなく依存になる。なぜならばその生成する方のの状態に影響を与えないからだ。 しかし、それがシングルトンとなると話は変わる。呼ばれる時にそのシングルトンがどういう状…

書かれた設計ドキュメント

作るドキュメントは最小限にしようというのは、アジャイル系プロセスの考え方ですが ドメイン駆動では正確な指針を提供しています。。 ドキュメントはコードや会話での表現を補うために作る 既にコードで表現できているものは書かない。まあ、綺麗に設計実装…

1つのチームに1つの言語

ドメイン駆動設計の勉強です。 開発側で統一するのはもちろんの事、ドメインエキスパートと開発側で一つ用語を使います。さすがにクラス名やメソッド名とかに使う英語は使わないと思いますが。 ただ、以下の理由で現実には難しいかな? (設計、実装の段階に…

ドメイン駆動設計「声に出してモデリングする。」

モデリングに限らず言語化するのは需要。書籍「UMLセルフレビューノート」や「ストリームラインオブジェクトモデリング」でも声に出す事を奨励している。 関係ないけど、このブログも色々駄文を書いて曖昧にしていた事が色々理解できた。ただ、声に出しては…

ドメイン駆動設計、読書

ドメイン駆動設計のユキビタス言語の所を読んだ結果です。 ドメインモデルとメンバーとの間で使う用語を合わせる。 モデルをユキビタス言語の骨格に使う。 使うユキビタス言語が変わる場合、ソースをリファクタリングする。 ユキビタス言語が変わる場合、モ…

ドメインモデル貧血症についてのその後

iOSアプリでのドメイン貧血症について - 概念構築メモ iOSアプリでのドメイン貧血症について - 概念構築メモ のついて悩みに悩んで、とある開発会社のコラムに似たような事が書いてあった。端的にいうとこれ。 モデル⇔ビュー、モデル⇔ネットワーク、モデル⇔R…

ファクトリーメソッドを積極的に作る。

オブジェクトの生成処理は長くなりがちです。1箇所だけしか呼ばれていないのに作るのは過剰設計じゃないかと思っていた時期も有りましたが、ドメイン駆動設計等、いろいろ文献等を読みあさった結果、以下の理由により、それでもファクトリーメソッドとして…

NSPredicateを使って、ドメイン駆動設計でいう「Specification」を表現する。

はじめに ご存じのとおり、iOSのNSPredicateクラスは配列をフィルターしたり、Core Dataでフェッチするための条件に使う物です。 条件文は複雑になり読みづらいですが、ドメイン駆動設計で言う「Specification」に基づいて、抽出条件を連想しやすいコンスト…