みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
この記事は Scala Advent Calendar 2013 12/11 の記事です。 昨日は @chiral さんの Sprayの簡単な紹介 - アドファイブ日記 でした。 ちゃんと見ましたか? 見てね! で、この記事は Scala で DDD の Repository の実装を書く場合どう書けばいいのか、その一例を考えてみたというお話しです。 (主軸が Scala より DDD な気がするがキニシナイ) ただし、書いてる人の関数型成分含有率は 1% 位な為、関数型ガチ勢から見た時いろいろ思うところがある可能性は高いです。 マサカリお待ちしております。 DDD 関連の概念については特に説明しないので適当にググってください。 実現したい要件 Repository の実装パターンを考えるにあたり、達成したい要件としては以下の2点。 ドメイン層(Repository)を特定の永続化技術から
こんにちは!グリープラットフォームでSNSの開発をしています、うきょーです! GREE Advent Calendar 2013 6日目です、よろしくお願いします! 今回は僕が所属するチームでの、ドメイン駆動設計を実践してきた過程をお話したいと思います。ドメイン駆動設計とは何か、については簡単に要所要所で説明していきますが、詳しくは本で!また、ドメイン駆動設計そのものについての話ではなく、実践の一例となります。 スマートUIパターンからのスタート 今回僕のチームが扱っていたものはJavaScript製のクライアントアプリケーションで、APIから取得した情報を表示し、ユーザーの操作によってAPIを呼び出す、というごく一般的なものです。 ドメイン駆動設計にはアンチパターンとして、スマートUIパターンと呼ばれるものが存在します。簡単に言えば「見た目都合から設計やモデルを考えてしまった」という状況
Swift is the best programming language you should learn and make your dream app easily. Swift programming is a powerful yet easy-to-learn coding language created by Apple. It's frequently used for developing iOS and macOS applications, as well as tvOS and watchOS apps. While you can use other languages to create Apple apps, Swift is the preferred language, and it's recommended because its code is
After working on a few projects where used C# and Domain Driven Design (DDD), I realized that there are some nice benefits about applying the ideas behind DDD in a software project. I started to wonder if we could apply the ideas from DDD in Haskell. This post explores a very simple Haskell application (for demonstration purposes) to see how the ideas of DDD fit in with Haskell. Another question I
昨日もDDDの話題を少ししたので、シナリオ→モデル→コードのサイクルについて身近な例を踏まえてネタを提供できないかと思った。何でもいいんだけど、鍼とか整体とかマッサージとか一度は行った経験あると思うので、そのドメインで考えてみるか。 実際は仕事に詳しい人を、ドメインエキスパートにした方がいいだろうけど、今回は自分でやってみる。 シナリオからドメインモデルを考える ドメインモデルにでてきそうな概念を、ひとまず人モノなどのリソースから考えてみたい。 患者 施術師 施術方法 まずはこれぐらいから。 このドメインは、患者が施術師の時間を予約することが目的です1。 簡単にシナリオを考えてみる。 患者が施術師の空き時間を予約できる。 患者が施術師に予約を要求(以下, 予約要求)する。 予約要求には、患者番号, 開始日時, 施術方法が必要。 施術方法には、マッサージ30分コース、マッサージ60分コースが
2013-03-23 DDDコナミ感 (Java-ja.ddd行ってきたよ) DDD java-ja java-ja.ddd行ってきました。ブログを書くまでが java-ja.ddd らしいので、ちょっとした小並感を書いてみます。 java-ja.dddはドメイン駆動開発(DDD)の勉強会なんですが、そもそもエリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) (DDD本) を買ったはいいけど積んだまま読んでなかったり、ここ数日シムシティ廃人してて平均睡眠時間が三時間切ってるのもあって、色々間違ったこと書いてるかもしれませんので、間違いなどがあるかもしれないという前提でお読みください&突っ込み、マサカリなど適当に投げてください。特にjava-ja方面の方よろしくお願いします。 第一部ざっくりDDD入門!! ドメイン = 業務知識 ド
第二回あーだCoderをやってきました。 - #あーだCoder 第二回 - connpass 解説すると、あーだCoderというのは僕と@irofさんの間で勝手に盛り上がっていつの間にかconnpassたったのでとりあえずやってみるかと始まったコード中心にモデル実装なんかを語る場。 今回は割りとじっくりとコードを見て、それから解説をしてもらいました。 特に興味深かったのが@ktz_aliasさんのコード。 - Codersation/TDDBC_VendorMachine/ktz_alias at master · posaunehm/Codersation · GitHub Data Context Interaction : DCIアーキテクチャ、というのがあるらしくて(本気で初耳)、それについてつらつらと議論して(というか教授してもらって)いました。 とりあえず、札幌Ruby会議で
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
ドメイン駆動設計やるならスモールオブジェクトプログラミング。オブジェクト指向の設計・実装の基本スタイル。Read less
レッツゴーデベロッパー2011での発表原稿とスライド 導入 2011年05月28日「レッツゴーデベロッパー2011@仙台」が開催されました。このイベントのテーマは「共有と交流」。"「共有」には、最新技術、知識、復興への想い、それぞれの決意を共有することを、「交流」には、東北と東北圏外のデベロッパーやコミュニティ同士の交流を深めることを込めて。" このイベントにてDDDセッションに登壇させて頂きましたので、そのときの発表原稿とスライドを公開致します。なお、当日はワークとして参加者の方にペアモデリングを行って頂きましたが、このドラフトではその部分を割愛しています。 スライドはこちら また映像はこちらで公開して頂いています。 さて今年4/9にDDD日本語版が出版されました。それから2ヶ月弱、翔泳社様から、はやくも増刷のお知らせを頂きました。多くの方々とおかげと深く感謝しています。さて、この増刷が
There are many kinds of complexity that you have to deal with developing software and different kinds of applications will have very different sets of problems you need to solve. If you are building the next Twitter, scalability and fault-tolerance are the problems you are probably fighting. On the other hand, these problems are almost never an issue when working on enterprise applications. The co
「Spring RooによるDDDの実践」勉強会の第2回を実施した。今回のテーマは 「Spring Rooのアーキテクチャ」。 Rooのアーキテクチャのハイライトは、ITDとスカフォルディング。 スクリプト言語であれば、スカフォルドとして生成されたコードと、 ユーザー定義のコードは、mix-inを使って結合する。あるいは、C#であれば、言語仕様として「パーシャルクラス」という仕掛けがある。Visual Studioでは、フォームデザイナなどが生成したコードと、ユーザーが書いたイベントハンドラを分離するためにパーシャルクラスを使っている。Visual Studioが生成したコードは別ファイルになっていて、ユーザーには見せないというわけ。 Javaには、自動生成コードとユーザー定義コードを、物理的に別ファイルとして分離する方法がない。そこで、RooはAspectJのIDTの力を借りることにした
We used the opportunity to streamline the Jira field values, so for example 25 component values in Jira correspond to 5 "in: *" labels on GitHub. The "status: *" and the "type: *" labels have also been given extra through and revised. Our choice of labels is aligned with the labels used in Spring Boot. The Boot team has given their process and labels a lot of thought, and we know the consistency w
Spring RooによるDDDの実践 ~ 第2回 Spring Rooのアーキテクチャ~ 2011年4月7日 笠原 規男 2 Spring Rooのキーメカニズム ITD ApectJのITD(インタータイプ宣言)を利用 クラスにメソッドや属性をウィービング ユーザーコード(.java)と自動生成コード(.aj)を分離 .ajはユーザーは編集不可 Ruby/GroovyのMix-in、C#のパーシャルクラスに似た方式 スカフォルディング Web層のモジュールを自動生成 RESTfullなController CRUD機能を備えたJSPX 「見た目」をカスタマイズ可能(CSS、アイコン等の差し替え) ラウンドトリップ可能 Entityへの属性追加がJSPXに反映される EntityへのFinderの追加がControllerおよびJ
「Domain-Driven Design」通称「DDD」の原著が出版されたのは、2003年のことだった。Kent Beck氏が賛辞に寄せた「思慮深いソフトウェア開発者全員の必携書」という言葉が示している通り、英語圏では圧倒的な支持を集め、出版から7年が経過した現在でも、Yahoo! Groupsのメーリングリストでは活発な議論が交わされている。 一方、日本では少し状況が異なる。識者の間では、有用な書籍として早くから知られていたものの、500ページ超という厚さと、文体の難しさが、多くの日本人エンジニアの挑戦を阻んできた(邦訳も待ち望まれたが、長い間出版されなかった)。 佐藤匡剛氏による「Domain-Driven Designのエッセンス」、徳武聡氏による「DDD Quickly 日本語版」をはじめ、日本語の情報は少なからず存在したし、国内での実践事例も徐々に蓄積されていたものの、本質的に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く