DDD
Domain-Driven Design
DDD は要求定義フェーズにおける「概念モデリング（Conceptual Modeling）」と絡めて講義を受けたことがきっかけで，多少理解できるようになった。 オニオン・アーキテクチャについては勉強しないとなぁ。つか，イマドキは企業やプロジェクトによってアーキテクチャが固まってるけどね。アーキテクチャ・レベルで試行錯誤する時期は過ぎてるのかもしれない。
私が最初に挙げた講義で習ったのはこれ。だいぶプログラマ寄りに書かれているせいか，上のオニオン・アーキテクチャとは発想が違っているようだ。この辺も DDD が敬遠される理由なのかな。 http://www.baldanders.info/spiegel/archive/DDD-fig.svg
ポイントは Data Layer のバックエンドにも DBMS や REST-API などが存在するってこと。つまりこの図の左側にユーザ（または別のサービス）がいて右側に別のサービスがいる，という想定。今時は複数のサービスが絡み合うので，このようなパイプライン的な構成になっていくわけだ。
この図のメリットは大規模 Web サービスから簡単な CLI (Command-Line Interface) まで描けてしまえること。たとえば，少し前にモンテカルロ法で円周率を求める遊びを Go 言語で書いてたんだけど，その時に描いた図がこれ。
http://text.baldanders.info/images/estimate-of-pi.svg
http://text.baldanders.info/images/icat4json.svg
これは要するに，このパッケージは Entity として使うんだよ，と説明したかったのである。今見るともう少し手直ししたい感じだけど（笑）
あと Facade Pattern を説明するのに使ったのがこれ。
http://text.baldanders.info/images/facade-pattern.svg
アーキテクチャの概念説明って理屈は分かるけど，やっぱり実際の業務に落とし込んでいかないと「理解」するのが難しいと思う。要求定義の段階から DDD のアーキテクチャを意識しながら議論していくと設計に落とし込む際に「理解」が早くなる。言い方を変えるなら，プログラマは要求定義の段階から参加すべきなのである。要求を都度 DDD アーキテクチャに落とし込んで積極的にプロトタイプを作っていく。そのプロトタイプは7割方すてることになると思うけど，捨てる度に理解が深まっていくのだ。 と考えていくと，プログラマにとって使い勝手のいいプログラミング言語とは（手続き型か関数型かではなく，今時な流行が取り入れられてるかでもなく）リファクタリングに手厚い言語である，と言える。
昔からある言語でも Ruby とかはリファクタリングに手厚い感じだよね。Ruby のメリットで「書いてて楽しい」という極めて感覚的な感想が出るのは，おそらくこの辺じゃないかと私は思っている。
個人的に注目している Go 言語もリファクタリングに手厚い言語で，実際に Google が巨大なリポジトリを管理できてる点から言ってもうなずけると思う。