Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
Railsでアプリを作っていると、最初の立ち上がりは速いものの、コードが多くなってくると結構散らかってきますよね。そんな中、5 ARCHIRECTURE ANTI-PATTERNS AND SOLUTIONS FOR LARGE RAILS APPSという記事を見つけたので、ご紹介します。 1. 複数の責務を持つサービスクラスがある 業務別の処理をサービスクラスという形で分割したときの話ですね。ActiveRecordのクラスに直接仕事をさせるのではなく、プレーンなクラスに業務処理をまとめて、そこからだけActiveRecordのクラスのオブジェクトにアクセスするという考え方です。 で、業務別の処理をサービスクラスにまとめたのは良いんだけど、「これもこの業務だよね」という感じで、どんどんサービスクラスに処理を追加していくと、単一責任の原則に違反してしまうし、混沌とするので、良くないよねと。
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設
渋谷オフィスを作り社会復帰して以来、チーム内でUI設計を標準化したいと、暇をみては色々なツールを試作している。その中の一部をとして、アプリケーション定義ステートメントの共有ツールをテスト公開。 アプリケーション定義ステートメントとは 聞き慣れない言葉ですが、大雑把にいうとアプリの本質を一言であらわしたコンセプト宣言。 家訓や社訓、電通鬼十則のアプリ開発版みたいなものであり、Appleは自社のヒューマンインターフェースガイドラインで、アプリ設計の最初にこのステートメント作成することを強く推奨しています。ステートメントがチーム全体で共有されていると、アプリがふらふらとブレずにしっかり芯が通ったものになる訳です。 アプリケーション定義ステートメントは、アプリケーションの主要な目的とその対象を、簡潔かつ具体的に宣言したものです。 アプリケーション定義ステートメントを開発作業の早い段階で作成しておく
移転しました http://please-sleep.cou929.nu/20130121.html
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文:NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く