努力する人が最後には”できる人”になる - かとじゅんの技術日誌
先日の2月3日で39歳になりました。社会人20年を振り返ると苦労の歴史でした。でも、それは誇らしいことでもあります。 今でこそ「できる人」というイメージが強いかもしれませんが、、駆け出しのころは全くできない子でした。 ということで、苦労話。タイトルがありきたりですが、でも難しいことなんであえてつけてみた。押し付ける気も全くないですけど、できるやつが何 後付でカッコつけてんだよ！とか、非論理的だなって言われると思います。それは否定しません。そんなことは承知の上で、以下 おやじのうんちくをたれます。 限界を超えた努力 初めてのプログラミングは10歳の時にBASICでプログラムです。なんか難しいこと簡単にやらせてみたい欲求があって、PCというのは難しいけど楽しいかもしれないと思った。その頃の「好き」のレベルはまだ淡い幻想です。 それ以来、社会人になるまでPCはゲーム機でしたが、社会人になってC言
ウェブアプリケーションの構造について - かとじゅんの技術日誌
日経ソフトウエア 11月号の特集2で「最新Eclipseで良いJavaプログラムを書こう」に関連する話題として、さらに視野を広げて実用的なウェブアプリケーションでのレイヤー構造とかドメインオブジェクトの関係はどうなるのか？という点について解説してみたいと思います。(まだ日経ソフトウエア11月号を手にしていない方はぜひ買ってくださいw) 結論から先に出しますが、ドメイン駆動設計では一般論として下図のようなレイヤー構造やオブジェクトの関連が提唱されています。 ドメイン層のオブジェクトについては変わりないのですが、ドメイン以外のレイヤーに新しく２つのサービスが登場しているので、まずそこから簡単に説明します。 ドメイン層以外のサービス 実はサービスはドメイン層だけではなく、アプリケーション層とインフラストラクチャ層にも存在する場合があります。その役割を以下にまとめてみました。 レイヤー オブジェク
コードで学ぶドメイン駆動設計入門 〜アグリゲート編〜 - かとじゅんの技術日誌
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜振る舞いとサービス編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜ファクトリ編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜リポジトリ編〜 - じゅんいち☆かとうの技術日誌 引き続き連投エントリ。次はアグリゲート。 実は最近まで「アグリゲートってなんだろう、、ライフサイクルの話題なのか」なって誤認識してたのですが、もう一度原書を読みなおして、やっと理解。まぁ、このパターンはすでに実施していたので、改めてこれはアグリゲートという名前かと知ったという次第。 つまるところ、アグリゲートとは、簡単にいうとライフサイクルを取り扱う境界のことですね。そもそも、Aggregateとは集約という意味があって
コードで学ぶドメイン駆動設計入門 〜リポジトリ編〜 - かとじゅんの技術日誌
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜振る舞いとサービス編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜ファクトリ編〜 - じゅんいち☆かとうの技術日誌 引き続き連投エントリ。私も来年で39歳になります。そして息子が7歳。いいおやじですが、脳は衰えないと言われています。鍛えれば鍛えたほど進化できると信じます。 ということで、リポジトリ編に入ります。 リポジトリ リポジトリは、ライフサイクルの途中から最後にフォーカスし、オブジェクトの永続化と永続化されたそのオブジェクトを検索する手段を提供するオブジェクトです。このように説明すると、DAOに近い印象を持つかもしれませんが、DAOはRDBMSやSQLなどのインフラストラクチャ層の関心事を含んでいるので、ここでは
コードで学ぶドメイン駆動設計入門 〜ファクトリ編〜 - かとじゅんの技術日誌
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜振る舞いとサービス編〜 - じゅんいち☆かとうの技術日誌 と続いて、このエントリはファクトリ編を解説します。 ドメインオブジェクトのライフサイクル これまで紹介したエンティティやバリューオブジェクト、サービス(以下、これらをドメインオブジェクトと呼ぶことにします)はライフサイクルを持っています。 ライフサイクルと聞くと、newされてからGCされるまでの間を想像します。しかし、一般的なアプリケーションでは、実際はVMのライフサイクルを超えるライフサイクルを扱うことが多いと思います。たとえば、テキストエディタで編集したデータを永続化する場合などです。テキストエディタのデータは単なるバイト配列と捉えるのではなく、ドメインモデルとして捉えることができます
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - かとじゅんの技術日誌
先日、DevLOVEで発表した「コードで学ぶドメイン駆動設計入門」ですが、入門としながらも難しかったかもしれません。モデリングの話は難しい方の話題なので仕方ないのですが、できるだけわかりやすく補足するブログを書いてみたいと思います。 まず、レイヤードアーキテクチャの話ですが、こちらのスライドを参照してください。 DEVLOVE HangarFlight で話したスライド&ソースコード - じゅんいち☆かとうの技術日誌 平たく言うと、そのアプリケーションが解決する問題の領域がドメインです。ドメインとそれ以外のものをごっちゃにしないようにしたのが、ドメイン駆動設計だと考えればよいと思います。 一般的に業務システムでは、対象業務がドメインに成り得ますので、ドメインは業務に準えて語られることが多いと思います。ドメインに登場する概念をユビキタス言語*1として定義し、モデルに落としこむというのが設計の
シナリオ -> モデル -> コード -> - じゅんいち☆かとうの技術日誌
昨日もDDDの話題を少ししたので、シナリオ→モデル→コードのサイクルについて身近な例を踏まえてネタを提供できないかと思った。何でもいいんだけど、鍼とか整体とかマッサージとか一度は行った経験あると思うので、そのドメインで考えてみるか。 実際は仕事に詳しい人を、ドメインエキスパートにした方がいいだろうけど、今回は自分でやってみる。 シナリオからドメインモデルを考える ドメインモデルにでてきそうな概念を、ひとまず人モノなどのリソースから考えてみたい。 患者 施術師 施術方法 まずはこれぐらいから。 このドメインは、患者が施術師の時間を予約することが目的です1。 簡単にシナリオを考えてみる。 患者が施術師の空き時間を予約できる。 患者が施術師に予約を要求(以下, 予約要求)する。 予約要求には、患者番号, 開始日時, 施術方法が必要。 施術方法には、マッサージ30分コース、マッサージ60分コースが
ユビキタス言語とドメインモデル、そしてモデル探求うずまき - じゅんいち☆かとうの技術日誌
最近、ドメイン駆動設計ってどうやって実践すればいいかなーという質問をよくされるので、この記事が満額回答にはならないと思いますが、書いてみたいと思います。 シンプルな問題はトランザクションスクリプト、いわゆる手続き型で対処できます。問題が小さいのでコードは直接的でわかりやすくなる傾向にあります。 とはいえ、世の中の問題はシンプルなものばかりじゃない。複雑な問題もある。DDDの著者であるEric氏は、複雑な問題はドメインモデルを使って対処すべきと説く。 ドメインとは問題の領域とか知識の範囲をいうのですが、DDDはそのドメインにある概念をモデル(ドメインモデル)として定義して、さらに実装として紐付けていく設計手法です。 モデルクラスは概念ありき 例えば、電車にまつわるドメインというので考えたとしたら 電車 乗客 駅 ダイア などの概念が登場します。 現実世界に限った話ではなく、仮想世界でもドメイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
