Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
[ 技術講座 ] Domain-Driven Designのエッセンス -目次-｜オブジェクトの広場
［技術講座］ DDD難民に捧げる Domain-Driven Designのエッセンス 第 1 回 ドメイン駆動設計とは 第 2 回 DDDの基礎と実践 第 3 回 大規模なプロジェクトへの適用 DDDパターンカタログ パターン名 参考訳 I. Putting the Domain Model to Work Ubiquitous Language ユビキタス言語 Model-Driven Design モデル駆動設計 Hands-On Modeler 実践的モデラー II. Building Blocks of a Model-Driven Design Layered Architecture 層状アーキテクチャ Smart UI （アンチパターン） 利口なUI Entities エンティティ Value Objects 値オブジェクト Services サービス Modules モジ
Living Documentation by design, with Domain-Driven Designを読んだ
Living Documentation by design, with Domain-Driven Designを読んだ Living Documentation by design, with Domain-Driven Design by Cyrille Martraire [PDF/iPad/Kindle]という電子書籍を読んだ。 leanpubで$0から購入できて、任意の値段で購入できるドキュメンテーションとDDDについての書籍。 追記: 書籍版 Amazon.co.jp: Living Documentation: Continuous Knowledge Sharing by Design (English Edition) 電子書籍: Martraire, Cyrille: 洋書 ドキュメンテーションもソフトウェア開発のように設計やテストといったパターンやアプローチがありま
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - かとじゅんの技術日誌
先日、DevLOVEで発表した「コードで学ぶドメイン駆動設計入門」ですが、入門としながらも難しかったかもしれません。モデリングの話は難しい方の話題なので仕方ないのですが、できるだけわかりやすく補足するブログを書いてみたいと思います。 まず、レイヤードアーキテクチャの話ですが、こちらのスライドを参照してください。 DEVLOVE HangarFlight で話したスライド&ソースコード - じゅんいち☆かとうの技術日誌 平たく言うと、そのアプリケーションが解決する問題の領域がドメインです。ドメインとそれ以外のものをごっちゃにしないようにしたのが、ドメイン駆動設計だと考えればよいと思います。 一般的に業務システムでは、対象業務がドメインに成り得ますので、ドメインは業務に準えて語られることが多いと思います。ドメインに登場する概念をユビキタス言語*1として定義し、モデルに落としこむというのが設計の
コードで学ぶドメイン駆動設計入門 〜振る舞いとサービス編〜 - かとじゅんの技術日誌
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 からの連投エントリ。振る舞いとサービス編です。今回もコードを使って解説したいと思います。 サービスとは、モノとして扱うと不自然なものをサービスに分類しようという考えです。 ドメインで扱う概念の中には、1つの機能や処理が単体で存在していて、もの（オブジェクト）として扱うのが不自然なものもある。そうしたものは、サービスという形でユビキタス言語に組み込む。サービスは基本的に状態をもたない（stateless）。 佐藤さんが語られている通りに、従来のサービスとDDDのサービスはレイヤーの位置関係が違います。今までのサービスはDDDのアプリケーション層です。このエントリでは、今までのサービス(DDDのアプリケーション層)の話は一切出てこないので、今までのサービスの概念を一旦忘れましょうｗそう
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
