atm_09_tdのブックマーク - はてなブックマーク

ドメイン駆動設計の探求其の一モデルと実装を協調させる、とはどういうことか | GuildWorks Blog

どうも、ギルドワークス前川です。以前ご紹介した通り、ギルドワークスではドメイン駆動設計（DDD）の勉強会を社内で行っています。その中で出てきた指摘に、ハッとする物があったので、今回はそれについて、ご紹介します。「それ、ソースコードに書いてないじゃん」それは、DDDを前提においたコードレビューで飛び出した指摘でした。コードはかなりシンプルな、ユーザからの投稿とそれに関する感想を閲覧する、といったサービスに関するものでした。こういった場合、当然のように、『”投稿”がトップレベルのオブジェクトにあり、それにぶら下がる形で”感想”オブジェクトがある』という様なモデル化をしていました。一方このドメインにおいては、投稿もさることながら、投稿に対する感想の方がドメインにおける重要な関心事、なのでした。それを話した時に、弊社増田の口から飛び出たのが、、、「んで、それはソースコードの何処

atm_09_td 2015/08/12

ddd

リンク

Spring Boot アプリケーションをDockerで動かす第２回 | GuildWorks Blog

河上です。前回に引き続き、Spring BootアプリケーションをDockerで動かしていきます。 Spring Boot アプリケーションはインメモリDBでの開発がとても楽ですが、リリース前はやはり本番と同じデータベースサーバで動作を確認したくなります。そして、それを行うにしても以下のような作業を行う必要があって本当に面倒です。データベースサーバのインストールと起動スキーマを作成するSQLの実行テストデータの登録アプリケーションの起動もう１つ、これらを手動で行っている場合の大きな問題点としてデータベースの状態が毎回変わる、もしくはどういう状態かわからないのでテストしにくいという問題があります。今回は、これらの問題を解消すべくDockerコンテナを使って自動化してしまいます。 Dockerは1.5が出ていますが、まだ1.4です。データーベースサーバは、PostgreSQL

atm_09_td 2015/02/19

Spring Boot

リンク

ドメイン駆動設計のリファレンス本 | GuildWorks Blog

井上です。現在、ドメイン駆動設計(Domain Driven Desing . 以下 DDD)を用いて開発を行っています。 DDDの参考書籍といえば、もちろん「エリック・エヴァンスのドメイン駆動設計ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本)ですが、その著者であるエリック・エヴァンスが最近(2014/9/22)「Domain-Driven Design Reference: Definitions and Pattern Summaries」という新しい本(以下 DDDリファレンス本)を出していることに気がつきました。 DDDリファレンス本とは早速DDDリファレンス本を取り寄せてみました。８８ページと非常にコンパクトな本になっています。内容的には、以下で公開されているPDFに新しい図や写真を追加してペーパーバックとして出版したもののようです。 DDD REFERE

atm_09_td 2014/11/21

ddd

リンク

ドメインモデル中心のアーキテクチャ | GuildWorks Blog

atm_09_td 2014/11/15

アーキテクチャ

リンク

Effective Java 第２版を可視化する | GuildWorks Blog

井上です。どのプログラム言語においても、必読書と呼ばれる本が何冊か存在すると思います。私は長らく使っているJavaでは「Effective Java 第２版」が真っ先に挙げられると思います。この本、初版が出版されたのが２００１年、第２版が出版されたのが２００８年なのですが、諸事情により一時期絶版になっていました。しかし、今年の３月にめでたく再販となりました。私自身、今でもたまに読み返す程手放せない本になっています。＃ただ、２００８年出版ということもあり、バージョンとしては Java 5 対応の内容となっており、Java 8 対応の第３版の発売を期待したいところです。さて、Effective Java のような技術書を読む場合、皆さんはどのように読み進めるでしょうか？最初から順に読む人も多いのではないでしょうか？しかし、Effective Java を初めて読む人がその方法で

atm_09_td 2014/10/19

Java

リンク

パッケージ間の循環依存を自動で検出する | GuildWorks Blog

この場合、「ドメイン」パッケージと「インフラストラクチャ」パッケージが相互参照しており、循環依存がある状態です。この状態で「インフラストラクチャ」パッケージに含まれるクラスを修正すると、相互参照している「ドメイン」パッケージだけではなく、「ドメイン」パッケージに依存している「アプリケーション」パッケージと「ユーザインタフェース」パッケージにまで影響範囲が及んでしまいます。このように、パッケージ間に循環依存がある状態というのは、望ましくない状態であると言えます。では、パッケージの依存関係をどのようにチェックしたら良いでしょうか？クラス数／パッケージ数が少ないうちは人力でもなんとかなるかもしれませんが、ある程度の規模になるとそれは非常に困難になります。そこでツールを活用することにします。先に挙げた本で紹介されているパッケージのメトリクス情報を計測することが出来るツール類がいくつも公開