別のアプローチによる実装の記事を書きました。 よろしければこちらもご覧ください。 「かんばん」を、DDDで設計しRailsで実装してみました。 kanban_core_extension 現時点では、最小限の機能しかありませんが ドメイン駆動設計をRailsで実装する際の一例として参考になれば幸いです。 アプリケーションの機能 開発するフィーチャ（タスク）をカードで表現し、進捗状況をかんばんボードで可視化する カードを次のフェーズ（進捗の区切り）に進める時にWIP制限をチェックする アーキテクチャスタイル Event SourcingなしのCQRSです。 変更（Command）の時だけドメインモデルを使います。 問い合わせ（Query）では、必要なデータをデータベースから直接取得します。 リポジトリからドメインモデルを取得することはしません。 取得したデータは構造化されたオブジェクトですが

PlayFrameWorkはイベント駆動型を基本としているため、全ての処理は非同期で実行される事が前提となっています。 これによって単一スレッドで複数のリクエストを捌く事ができます。 非同期のHTTP呼び出しを実現するPlay WS APIを使って外部のWebサイトにアクセスするコードを例にして、非同期処理でクライアントからのリクエストがどう扱われるか見てみます。 非同期処理でのリクエスト挙動 非同期で外部Webサイトにアクセスするコントローラ public class TestController extends Controller { public static F.Promise<Result> nonBlockingUrlAccess() { final String uniqueId = UUID.randomUUID().toString(); Logger.debug("r

(3/15 : タイトル修正しました。wは小文字ですね、すみません・・・) PlayFrameworkが流行り始めてから割と経ちますので、そろそろ正式採用しようと考える方も多いのではないかと思います。 強力な静的型付けで守られたPlayは、ミッションクリティカルなシステムや数万行を超える大規模システムの構築に特に向いているような気がします。 また、Servletを使っていないのに加えてMVC構造がベースなので、今までRailsなどで開発をしていた人でもシームレスに移行できると思います。 しかし、忘れてはならないのがPlayのアーキテクチャが全ての処理が非同期で行われることを前提としているという事です。 ここを忘れてPlayをただの強力な静的型付けで守られたMVCフレームワークとだけ考えて開発を進めてしまうと、本番環境で稼動させた時にパフォーマンスが上がらずに困ることになるかもしれません。今

scaffold を制するものは rails を制す、という言い伝えがありますが、 rails g scaffold User などとすると routes.rb に突如現れるのが、 resources というやつです。 いまここに、Group と User という2つのモデルがあり、 Group が has_many :users で、 User が belongs_to :group だとしましょう。よくある関係ですね。 このような場合に、resources を こんな風に nest すると、新規に User を作る時の URL が /groups/:group_id/users/new となり、自然な形で group_id を渡すことができます。 ところが、このように routes を定義すると、いざ User が生成された後にその User を show するには /groups/: