はぶあぶれーく

IT技術の勉強に関して記録していく備忘録的なものです。

DDDしてみた

2017/6/24のKANJAVA PARTY 2017 !!!で@haljik さんのセッションを見て、挑戦してみました。

普段使いのDDD // Speaker Deck

 

作るもの

お題として、簡単なSNSを作ろうと思います。

誰かが「投稿した記事を、誰でも見れる。」というだけの超簡素なSNSです。

 

人・物・事分析

その業務に登場する、人・物・事を並べたてます。

  • 人=投稿者、閲覧者
  • 物=記事
  • 事=閲覧、投稿、検索、コメント

こんな感じでしょうか。

まず、人としては、投稿者と閲覧者がいます。

物は記事だけかと思います。記事に対して何か事を起こします。

事は、閲覧者が記事の検索、閲覧、コメントをしたいですし、投稿者は投稿したいです。

 

時系列

独立してある人や物をまず並べてそれが起こす主要なイベントを時系列で並べます。

  1. 投稿者と閲覧者がいる
  2. 投稿者が記事を投稿する
  3. 閲覧者が記事を検索する
  4. 閲覧者が記事を閲覧する
  5. 閲覧者が記事にコメントをする
  6. 投稿者が記事にコメントを返す

こんな感じで並べてみました。

 

モデル化

人・物・事分析で出た要素を時系列分析で関連付けし、依存の方向を決めます。

 

f:id:bird_cage313:20170715003416p:plain

 

モデル図はこんな感じで作ってみました。

 作ってみてわかったんですが、矢印が記事に集中してるんですね。つまりこのアプリケーションのコアドメイン記事だという事がわかります。

このアプリケーションは小さいものなのでそんなの最初からわかってるよって思うかも知れませんが、ちゃんと分析でも想定してた結果が出たのがおもしろい。

こうして、ちゃんと分析してコアドメインを把握していくのですね。

 

コードを書く 

これをそのままコードに落とし込んでみます。

投稿者

public class Author {

private String name;

public Author(String name) {
this.name = name;
}

}

記事
public class Article {
private Identifier identifier;
private Author author;
private Title title;
private Contents contents;

public Article(Identifier identifier, Author author, Title title, Contents contents) {
this.identifier = identifier;
this.author = author;
this.title = title;
this.contents = contents;
}
}

検索
public class Search {
private Articles articles;

public Search(Articles articles) {
this.articles = articles;
}
}

これ、ちょっとおもしろいんですが、Searchというクラスがあってその中にArticlesクラスがあるんですよね。
まあモデル図通りに書いてるのでそうっちゃそうなんですが。

僕がこの分析をせずにコードを書くなら、間違いなくArticleクラスかArticleServiceクラスを作ってそこにsearchメソッドを書くと思います。

分析して作ったクラスは逆なんですよね。でもそっちの方が妙にしっくりくるというか、使うときも Search.articles と書くはずなので英語の文としてもかなりしっくりくる。
これはありかもしれない…!


まとめ

コード少ししか書いてないけどかなり気づきが得られた。コードを書く前に業務を分析することは大事です。