Eric Evansの有名な本『Domain-Driven Design: Tackling Complexity in the Heart of Software』の要約版として、InfoQが出しているもの。
無料でダウンロード可能（登録は必要）
日本語版 (こちらは登録不要でダウンロードできた）
OutSystemsも公式ドキュメントとして、DDDに基づくガイドが出ているので、その理解のために要約版に一通り目を通したのでメモ。
なお、OutSystemsにおけるDDDについては、Qiitaに概要のメモを作成してあるのでそちらを参照：OutSystemsのDDD情報まとめ
- 要約版でも内容が抽象的で難しい。この辺りをちゃんとやるなら何度か読み直す必要がありそう
- ビジネスプロセスや作成するソフトウェアで解こうとしている問題がドメインで、ドメイン駆動設計は、ソフトウェアをこのドメインと調和するように作るためのもの
- そのために、ドメインをソフトウェアに反映させるとか、ドメインをモデリングする必要がある。OutSystemsではドメインはLifeTimeのTeamにマッピングされるが、Teamはモデルと考えるにはちょっと違和感がある（Teamというのは、要するにアプリケーションとそれに対するITユーザーの権限の組み合わせでしかないので）
- 出来上がったドメイン内のコードを読むことで、ドメインの業務知識を学べるようにすべき、というのはどうか。OutSystemsでいうと、ドメイン（Team）内のモジュールの参照関係、各要素のDescription・コメント・命名から読み取れるように、ということだと思うが、難しそう
- 現状、OutSystemsではTeam=ドメインへの分割までをDDD的にやって、その中は自由に（Architecture Canvasの方法には従って）作っていくのがやりやすい。ForgeにあるDiscoveryにはTeam=ドメインを管理して一覧表示するような機能が追加されている
- あちこちで開示されているDDDの、業務知識をモデリングしてドメインにまとめていくノウハウは当然ながら、オブジェクト指向言語用。OutSystems用には公式ドキュメントを元にノウハウを構築していく必要がありそう（もちろん、OOP用のノウハウで流用できる部分もあるとは思うが）。モデリングパターンとかモデリング例とかがないと厳しい
- この資料に書かれているアーキテクチャ（User Interface, Application, Domain, Infrastructure Layer) はOOP用と考えて、OutSystemsでは別になると思われる。Domainの概念はTeamと対応するので、これを抜いて考えると、Architecture Canvasの3つのレイヤに落ち着く
- リファクタリングについて。自動テストでガードしてコードを改善していくリファクタリングの他に、ドメインに対する知識が深まったときにその知識を取り込むようにモデル（とその先にいるコード）を改善するリファクタリングもある、と紹介されている
- 後者のリファクタリング用のパターンがいくつか紹介されている。こちらは、OutSystemsのTeamsの設計への適用が検討できそう。問題は開発者が増えるとTeamのメンテナンスもそれなりに面倒なことだが