I read 『Web世代が知らないエンタープライズシステム設計』IT勉強宴会（著） (‘Enterprise System Design That the Web Generation Doesn’t Know’ by IT Study Banquet), so I’ll share the insights I gained from the book.

Background: Want to Learn Enterprise System Design

Since I’m from the web generation and want to learn enterprise system design, I read this book.

Below are quotes from memorable sections and my notes.

Chapter 2: The Real Fear of "Learning Too Much Programming" - Essential Knowledge to Avoid Becoming an Implementation Uncle

適用分野の専門性について他人をアテにしてはいけない

この辺りに関して筆者が懸念しているのが、昨今のドメイン駆動設計（ DDD）の盛り上がりである。エリック・エヴァンスが提唱した DDDはもともと、「適用分野に関する知識」を対象のソフトウエアに組み込むための、モデリングを核とする汎用的な枠組みだった。言ってみれば当たり前の指摘ではあったのだが、実装技術ばかりに注目しがちな技術者に良いアドバイスになると筆者も共感したものだ。

ところが日本における DDDは、いつの間にか「オブジェクト指向プログラミングの現代的なスタイル」とみなされてしまう。その過程で「適用分野に関する知識」の重要性は、そういった知見を持つ「ドメインエキスパート」との協働の必要性にすり替えられた。 適用分野の専門性がなくても、それを有する専門家と協働すれば良いソフトウエアが出来上がる──こう考えているとしたら幻想である。創造的なソフトウエアというものは、専門家による構想と、その分野の専門性を一定以上持つ開発者の技能とが融合して初めて生み出される。

なぜなら専門家の構想はたいていあいまいで不定形で、場合によっては的外れだったりするからだ。これをまとまりのあるソフトウエアとして仕上げていくには、開発者にもその分野に関する一定以上の専門性が欠かせない。

もし、「適用分野に関する専門性は自分以外の誰かによって供給される。自分は実装技術を究めればいい」と考えるようになるなら、それは歪曲（わいきょく）された DDDであり、学びは害悪でしかない。プロダクトオーナーが持つ専門性をあてにしているという意味では、アジャイル手法の一種であるスクラムにも同様の危うさがある。

💡 Distorted DDD is harmful

Chapter 3: Customer Requirements Too Vague? Professionals Hone Their "Expertise" Before Lamenting

エンタープライズシステムにおける専門性は 3点ある

簿記を含む多業種向けの業務知識」「システム要件を具体的な設計仕様に落とし込むスキル」「システム開発に最適化された実装スキル」、これら 3点がエンタープライズシステムでの専門性だと筆者は考える。

Above, I want to learn enterprise system design.

That’s all from the Gemba.