Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
![実践的な設計って、なんだろう?](https://cdn-ak-scissors.b.st-hatena.com/image/square/fd5ef2b7d3a24ca12ab65e36b1f750e5e60a62d1/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fa-140517222451-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Copyright © GREE, Inc. All Rights Reserved. (Scala ) 2014/04/30 Version 1.0 Copyright © GREE, Inc. All Rights Reserved. • • 10 : F-BASIC, N88-BASIC • 20 : (x86), C/C++ • 30 : Java, Seasar2, OSS, DDD • 40 : DDD, Scala, Finagle/Trinity • • + 2 Copyright © GREE, Inc. All Rights Reserved. Copyright © GREE, Inc. All Rights Reserved. Scala DDD Copyright © GREE, Inc. All Rights Reserved. • • • 5 Copyrigh
6月23日(土)午後、大阪で、ドメイン駆動設計について、しゃべる予定。 第47回 SEA関西プロセス分科会のご案内 紹介の紹介の紹介、みたいな不思議なつながりで、講演の依頼があった。 「ドメイン駆動設計」を監訳された今関さんも参加いただける。 土曜の午後なので、時間が多め。 一方的にしゃべって終わりではなく、今関さんも交え参加者で、いろいろ話す時間を一時間以上とってもらいました(さらに懇親会もゆっくりと)。とても楽しみなイベントです。 ドメイン駆動設計は、訳本がでてから、あちこちで勉強会や読書会が開かれているようだし、ドメイン駆動設計に興味持ったり、現場で取り組む人が、すごく増えた気がしている。 ネットで流れる情報も「ドメイン駆動ってなんぞや?」的なものだけでなく「私は、こう理解している、やっている」的なものが多くなったんじゃないかなあ。 訳本の威力は絶大。 さて、講演の準備は、いつものよ
Many esteemed books on code architecture were written by developers with years of experience in strong OOP languages, such as Smalltalk and Java. These languages grew up without a lot of the framework tooling we have today. In fact, these same authors and developers created most of the development practices we use today. Many frameworks in our more "modern" languages were born from the lessons tau
Using the Specification Pattern for Querying 11 September, 2009. It was a Friday. The specification pattern is great for adhering to the Single Responsibility Principle (SRP). The reason it can be so powerful is that it encapsulates one piece of logic, and nothing more. I’ve decided to come up with some code that takes advantage of this very easily readable and maintainable code structure. What Is
あるエンティティに対して、何らかの条件を満たすものをグループとして扱いたいことがよくあります。安直な実装としては、条件を加味してエンティティを抽出するようなメソッドをリポジトリに追加する方法をとってしまうかもしれません。 このようにリポジトリにメソッドを持たせてしまうと、条件が集合操作の中に埋もれてしまい、再利用しづらくなります。そこでDDDではSpecification(仕様)としてこういった条件をくくり出すパターンが紹介されています。『エリック・エヴァンスのドメイン駆動設計』p.229「仕様の適用と実装」では、次のように書かれています。 仕様の価値の多くは、全く異なるように見えるアプリケーションの機能を統一することにある。以下に挙げる3つの目的のうち、1つでも当てはまれば、オブジェクトの状態を(筆者注:仕様として)定義する必要があるだろう。 オブジェクトを検証して、何らかの要求を満たし
最近、ドメイン駆動設計ってどうやって実践すればいいかなーという質問をよくされるので、この記事が満額回答にはならないと思いますが、書いてみたいと思います。 シンプルな問題はトランザクションスクリプト、いわゆる手続き型で対処できます。問題が小さいのでコードは直接的でわかりやすくなる傾向にあります。 とはいえ、世の中の問題はシンプルなものばかりじゃない。複雑な問題もある。DDDの著者であるEric氏は、複雑な問題はドメインモデルを使って対処すべきと説く。 ドメインとは問題の領域とか知識の範囲をいうのですが、DDDはそのドメインにある概念をモデル(ドメインモデル)として定義して、さらに実装として紐付けていく設計手法です。 モデルクラスは概念ありき 例えば、電車にまつわるドメインというので考えたとしたら 電車 乗客 駅 ダイア などの概念が登場します。 現実世界に限った話ではなく、仮想世界でもドメイ
Redirect Notice The page you requested has been relocated to https://restfulobjects.org/spec/1.0/about.html.
In my country, you won't make it through school without reading how Goethe's Faust complains, I've studied now Philosophy - And Jurisprudence, Medicine, - And even, alas! Theology - All through and through with ardour keen! - Here now I stand, poor fool. Sadly, none of his efforts and studies helped the doctor to perceive whatever holds the world together in its inmost folds. And here we are in IT
If I had to separate projects I've been in, i would difference between data manipulation and enterprise projects. Data manipulation projects mainly consist of a set of forms needed to alter data which is stored in some persistent store (most of the time a relational database). In these projects, there is not much domain logic to be found. There might be some validation logic, some jobs running in
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く