ビッグローブでDDDを導入して早2年。 この2年間、ISP事業における主要なサービスをDDDで開発してきて、試行錯誤の連続でした。 今回は、試行錯誤の過程を経て生まれた、実際に実践している ・設計・実装の考え方(ドメインモデルやコード例やDB設計など) ・チーム環境の考え方(開発プロセスやチームビルディングなど) の2つを軸に現場でのリアルな体験を紹介します。 また、最後に、試行錯誤における失敗談も紹介します。 Read less
ビッグローブでDDDを導入して早2年。 この2年間、ISP事業における主要なサービスをDDDで開発してきて、試行錯誤の連続でした。 今回は、試行錯誤の過程を経て生まれた、実際に実践している ・設計・実装の考え方(ドメインモデルやコード例やDB設計など) ・チーム環境の考え方(開発プロセスやチームビルディングなど) の2つを軸に現場でのリアルな体験を紹介します。 また、最後に、試行錯誤における失敗談も紹介します。 Read less
おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何? まず基礎ということで、Flux i
In 2014, after two years of reading about and working with Domain-Driven Design, Carlos and Christian, friends and workmates, traveled to Berlin to participate in Vaughn Vernon's Implementing Domain-Driven Design Workshop. The training was fantastic, and all the concepts that were swirling around in their minds prior to the trip suddenly became very real. However, they were almost no PHP developer
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
Flux is an application architecture designed by Facebook for their JavaScript applications. It was first introduced by Facebook in May 2014, and it has since garnered much interest in the JavaScript community. There are several implementations of Flux. Frameworks like Fluxxor keep to the original Facebook Flux pattern, but reduces the amount of boilerplate code. While other frameworks like Reflux
Domain-Driven Design (DDD) is an approach for building high-quality products that meet the needs of a business and its customers. It emphasizes collaboration among domain experts, product managers, designers, engineers, and other disciplines to create a domain model that reflects these needs. This involves agreeing on common terminology, identifying business entities, and documenting the relations
いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計? from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが1つ。 で、ドメイン(特にいまやってる物事)を抽象化す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く