Stay Relevant and Grow Your Career in TechPremium ResultsPublish articles on SitePointDaily curated jobsLearning PathsDiscounts to dev toolsStart Free Trial7 Day Free Trial. Cancel Anytime. Key Takeaways Domain-Driven Design (DDD) and Rails often contradict each other, but the author seeks to reconcile these paradigms and find a way to use DDD without fighting Rails. DDD focuses on tackling domain
まずは、設計・実装における Value Object を整理した方が良さそうなのでまとめてみました。 Value Object の設計方法としては、以下の3通りがあると認識しています。 # 仕事で主に使用してきた言語が C++ と Java なので、もし他にもあればご教示ください。 1. Singleton インスタンスを1つしか生成しないパターンです。 Java の enum がこれに該当します。 同一性は == で判定することができます。 2. 不変オブジェクト インスタンスが1度生成されたら、属性の変更を許可しないパターンです。 Java のプリミティブ型のラッパークラス(Integer など)、String、BigDecimal などが該当します。 Java の場合、hash と equals メソッドをオーバライドする必要があります。 3. スコープ外へ公開する際に複製する クラ
Practical DDD with Scala - An Introduction Document Transcript Cover Page Practical Domain-Driven Design with Scala An Introduction Ivan A Krizsan Version: February 17, 2013 Copyright 2013 Ivan A Krizsan. All Rights Reserved. Table of ContentsCover Page...........................................................................................................................................1Table o
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
最近、ドメイン駆動設計ってどうやって実践すればいいかなーという質問をよくされるので、この記事が満額回答にはならないと思いますが、書いてみたいと思います。 シンプルな問題はトランザクションスクリプト、いわゆる手続き型で対処できます。問題が小さいのでコードは直接的でわかりやすくなる傾向にあります。 とはいえ、世の中の問題はシンプルなものばかりじゃない。複雑な問題もある。DDDの著者であるEric氏は、複雑な問題はドメインモデルを使って対処すべきと説く。 ドメインとは問題の領域とか知識の範囲をいうのですが、DDDはそのドメインにある概念をモデル(ドメインモデル)として定義して、さらに実装として紐付けていく設計手法です。 モデルクラスは概念ありき 例えば、電車にまつわるドメインというので考えたとしたら 電車 乗客 駅 ダイア などの概念が登場します。 現実世界に限った話ではなく、仮想世界でもドメイ
I have a domain model that has the concept of an Editor and a Project. An Editor owns a number of Projects, and a Project has not only an Editor owner, but also a number of Editor members. Therefore, an Editor also has a number of "joined" Projects. I am taking a DDD approach to modelling this and using the Repository pattern for persistence. However, I don't grok the pattern well enough yet to de
ちと、小難しい話になります。DDDの話なんで、 コードで学ぶドメイン駆動設計入門 〜アグリゲート編〜 - じゅんいち☆かとうの技術日誌 でも取り上げたアグリゲートに関する考察です。どうあるべきかはちょっと分かっていません。これを読んでこうしたらよいのでは？と思う方、意見歓迎です。インターネットって一方だと面白くないので議論したいですね。 アグリゲートってライフサイクルの境界を扱うための設計パターンです。ライフサイクルで思い出すのはリポジトリとファクトリ。この二つのオブジェクトが扱うのがアグリゲートです。ライフサイクルは至るところに出てくるので、結構大事で、設計の根幹に影響するオブジェクトのひとつではないかと思います。 アグリゲートは、内部のエンティティやバリューオブジェクトを集約している境界で、その境界はエンティティであり、ルートエンティティと呼ばれる。 グローバルな同一性を持つエンティテ
Frameworks We Live By: Design by day-to-day framework development: Multi-para...
What is Flow?Flow is a PHP web application framework focussed on Domain-Driven Design and clean code. Based on strong conventions and best practices, it allows you to rapidly create powerful web applications. Created with love by the Neos project. The photo at the top (by Astris1, CC-BY-SA 3.0) shows a Lorimerlite structure, the strongest isotropic truss for resisting compression. Similar to Flow
The document discusses pursuing Domain-Driven Design practices in PHP. It covers building blocks like entities, value objects, aggregates, repositories, factories and services. It also discusses data modeling approaches like moving from active record to data mapper patterns. The document provides examples of implementing these concepts in PHP using annotations and libraries like Doctrine. It aims
Cargo freighter passing under the Golden Gate bridge in San Fransisco. Image courtesy of FreeFoto.com. One of the most requested aids to coming up to speed on DDD has been a running example application. Starting from a simple set of functions and a model based on the cargo example used in Eric Evans' book, we have built a running application with which to demonstrate a practical implementation of
きっかけは、「オブジェクトからサービスへ」というエントリに対して、通りがかりさんからコメントいただいたことだった。これまで、長い間、もやもやしたものを感じていたのだ。 オブジェクト指向の本を紐解くと、データと振る舞いをクラスにカプセル化すると書かれている。僕も疑問は、そもそも、それが正しいのか、つまり、データに振る舞いを持たせる必要性があるのだろうか？賢いデータは必要なのか？ということだ。 Javaでは、データと振る舞いの分離が進んでいる まず、現状として、Javaの世界では、データと振る舞いの分離が大きくすすんでいる。EJBにしても、EntityBeanとSessionBeanというのは、データと振る舞いの関係にあり、分割がよいこととされている。さらに、O/Rマッピングツールが流行するにつれ、データの保持クラスはPOJOとなった。一方、ビジネスロジックは、FacadeやServiceと
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
