#domain.engineering

最初に、問題文―我々のメタファーにおける「クリアテキスト」―を記録することに再び焦点を合わせます。これは言葉のいかなる意味においてもプログラムではありません―対象領域の専門家の、彼らの専門用語や隠語、表記法を用いた、コントリビューションの直接的な記録にすぎません。次に、プログラマーが、問題そのものではなく、記録された問題文を受け取り、それからコードを生成する、エンコーダーのためのコンピューターコードとして、彼らのソフトウェアエンジニアリングの専門知識や意思決定をプログラムできるようにします。これは、ジェネレーティブプログラミングと呼ばれ、私はそれがソフトウェアの未来であると確信します。

the difficulties people find in DDD is mostly because of these implementation patterns which do not necessarily map to ‘Domain’ concepts.

上の２つの原則をとらえなおすと、境界線の線引きを変えようとしている事わかります。 ところが、我々が昔から行っているDOAアプローチはそれらを当然と考えているために今まであまり議論にもならなかった話です。事業活動のモデルとドメインモデルの境界線を「ユビキタス言語」」が担っているという意味です。ＤＯＡはそれを「帳簿組織」が担います。 　＜事業活動のモデル＞　　＜ドメインモデル＞　　＜プログラム構造＞ DDD　　　　　　　　ユビキタス言語　　　　　モデル駆動 DOA　　　　　　　　　帳簿組織　　　　　　自動生成／動的制御

The book is an excellent complement to Domain Specific Languages by Martin Fowler with Rebecca Parsons. Whereas Fowler’s book concentrates its focus on the generally well established methods for traditional, textually based DSL development with parsers and compilers, “DSL Engineering” takes a wider perspective and includes a more detailed discussion of modern Language Workbenches such as the Intentional Domain Workbench. The book compares both approaches and provides useful context for when each approach has an advantage.

フレームワークは、特定のドメイン向けに提供するものなので、構築にはドメイン分析・モデリングが不可欠である。

「初音ミク」のエディタがどんなに気が利いているとしても、利用者に作曲や編曲といったスキルや音楽性が欠けていたら使いこなせるものではない。つまりDSPは、「その適用分野で稼ぐために必要な専門性や適性がどういうものか」をあぶりだすための仕掛けでもある。

「リポジトリ（設計情報）が資産」という世界は、開発者にとって面白みに欠けるのではないか 案外、そうでもない、というのが実感です。設計情報のキモはモデリングです。実世界のモデル化は、設計者の視点で情報を取捨選択し、分解し、再統合するという高い創造性を要求される分野であり、プログラミングに勝るとも劣らない面白さがあります。モデリングには業務知識とコンピュータの仕組みの双方を知っている人が、理想と現実（ソフトやハードの制約条件）の中で、落としどころを探ることが求められており、さらに業務の変化によってモデルの形も変えていくことになります。決して素人がパラメータをちょっと設定するとアプリケーションができる、というものではありません。いわゆるシステムエンジニアという職種の醍醐味です。

マルチパラダイムデザインでは、アプリケーションエンジニアリングを開発プロセスの後半にまで遅延させるようなことはしない。むしろアプリケーションエンジニアリングは、ドメインエンジニアリングのアクティビティの中で重要な位置を占めることになる。