Domain-Driven Design (DDD)
3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いましたが、説明を端折ったところを中心にスライドの回顧をしています。 「Domain-Driven Design (DDD)」として用意した以下のスライドを説明します。 セッションの全体構成は以下のようになっています。 関数型プログラミング Object Functional Programming (OFP) Object Functional Analysis and Design (OFAD) 応用 この中で4番目「応用」は、今OOADやクラウド・プラットフォームで話題となっている技術がOFADでどのような影響を受けそうなのかということを考えてみる趣旨のセクションです。 具体的に考えてみることで、OFADへのイメージ
『DIコンテナとドメインモデルの相性の悪さ』
Seasar、SpringなどのDIコンテナを使っていると、ドメイン層の実装はデータ（Entity／Dto）と振る舞い（Service／Logic）に分ける、いわゆるトランザクションスクリプトのスタイルになりがちだ（参照(1)、(2)）。理由は、1つにはドメインモデルの設計／実装そのものの敷居が高いこともあるが、そのハードルを乗り越えても、DIコンテナそのものがドメインモデルと馴染みにくい側面があるからだと思われる。 DIコンテナはエンティティやDTOにDIできない その側面とは、次の通り。DIコンテナは設計思想からしてファクトリの役目をするものであるため、DIコンテナを使う場合、インスタンスの生成は基本的にDIコンテナが担当することになり、コンポーネントに必要なオブジェクトはすべてDIで渡されるような設計に誘導されてしまう DIを使ったWebアプリケーションのアーキテクチャは、まずリクエ
副作用を最小限に抑えるために必要なこと - かとじゅんの技術日誌
若干、難しい話ですが、設計力を上げたいプログラマ向けなエントリ。私も道半ばです。一緒に考えていただければ幸いです。 堅牢なアプリケーションを実現する上で「副作用を最小限に抑える」という設計思想は、非常に重要な示唆を含んでいます。 その「副作用」とは、そもそもどんな定義なのでしょうか。 DDDでは"side effect"と定義していて、以下のように解説されています。 Domain-Driven Design: Tackling Complexity in the Heart of Software: Evans, Eric: 8601300201665: Amazon.com: Books エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon P250より引用 In standard English, the term side effect implies
Side-Effect-Free Functions パターン : 副作用をなくす設計 | システム設計日記
コードが複雑になってくると、「副作用」が恐くて、コードを変更しにくくなる。 ちょっとした変更が、とんでもないところに影響がでる。 すぐに発覚するなら、まだまし。 本番リリース後、しばらくたってから発覚する「副作用」には、なんども痛い目にあわされてきた。 副作用の原因 ソフトウェア変更後の予想外の障害を調べてみれば、コードに「こうしろ」と書いてある箇所があり、コンピュータは、まじめにそれを実行しただけ。 副作用を起こしたコードの場所が、変更した箇所からは、遠く離れていて、変更した技術者には想像もつかなかったのが原因。 ・あるオブジェクトの一つのメソッドを実行する ・メソッドの中で別のメソッドを呼び出す ・その中で、今度は、オブジェクトを生成し、そのメソッドを呼び出す ・またメソッドを呼び出す ．．． 少し規模の大きいソフトウェアでは、普通の姿ですね。 シンプルで役割を明確にするために、小型の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
