Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
ドメイン駆動設計読んだ - hitode909の日記
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
エロゲーマーのためのSQL -エロゲーマーのためのSQL-
SQLはデータベースからデータを抽出したりするための言語です。 この文書は、ErogameScapeのデータベースからSELECTを使って自由自在にデータを取得できるようになることを目標にします。 エロゲーをやりはじめる大学生くらいのときに、大学の講義でデータベースを学んで、退屈だなーと思った時に、ErogameScapeでSQLを学ぶことで、少しでもSQLに興味を持って、自身でデータを加工することを学習して頂けると幸いです。 ※私の大学のリレーショナルデータベースの授業では、自分の身の回りの何かをER図に落とし込んで、DBを設計し、PostgreSQLに実装し、実際にデータを入力してSELECTしてみるところまでをやりました。 ER図という概念を学んだとき「ああ、これは面白い」と思いました。 先生はこう言ったのです。 「ER図に落とし込むと、思いもよらなかったことが分かる。」と。 当時、
Perlでコマンドラインモジュールを書くときのクラス設計 | おそらくはそれさえも平凡な日々
コマンドラインから引数が渡すようなモジュールでも以下のような要件があったりする。 コマンドラインからだけじゃなくて、コード内で直接オブジェクトをnewしたい場合もある 複数のコマンドラインツールを組み合わせて使うような場合に@ARGVを何度か渡すケースがある growthforecast.plみたいなサーバースクリプトだとよくあると思っていて、スクリプト単体で引数渡して起動できるけど、自分でGrowthForecast::Web->newしたくなることもある。これが前者。 growthforecast.plにPlackとGrowthForecastのオプションをコマンドラインから同時に渡したいみたいなのがある。これが後者。 GrowthForecastはあくまで例えです。念のため。 それに対しては以下のようにすればよいのかなーとなった。 parse_optionsというクラスメソッドで@A
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
UMLを描こう – Vol.6 ロバストネス図からシーケンス図を描く
こんにちは、浦本です。 今回はロバストネス図からシーケンス図を描く方法について、順を追って解説します。 シーケンス図の立ち位置 シーケンス図は、詳細設計の成果物の中で最も重要な図です。描く際はいきなりゼロから描くのではなく、ロバストネス図を参考にしながら描きます。下図に、開発プロセス全体におけるシーケンス図の立ち位置を示します。 ICONIX Processでは、設計プロセスを予備設計と詳細設計の2段階に分けて行います（これを2パス設計と呼びます）。まずは予備設計で、実際のクラスを気にせずに「システム全体としてどのような処理・対話をすべきか」を先に決めます。次に詳細設計で、具体的にどういったクラスにそれらの処理を割り振るかを決めていきます。事前にロバストネス図さえ描いていれば、要件定義にきちんと結びついたシーケンス図を描くことができます。詳細設計ではシーケンス図の他にも、必要に応じてクラス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計入門
bitbucketの使い方