このシリーズを作成する背景について
自分がアーキテクチャーに興味を持つ、社内でDDD（ドメイン駆動設計）という単語を聞きましたので、調べていくとますますいい設計だと思い、自分なりの理解を記事にしたく、このシリーズを書くことにしました。
あくまで個人の理解で、間違う部分もあると思いますが、勉強したことを忘れないように記録していきたいと考えています。
このシリーズの内容について
・DDD（ドメイン駆動設計）に関連する概念の説明
・実際DDD（ドメイン駆動設計）を使用し、サンプル用のシステムを開発していく
・仕様変更＆機能追加する際、DDD（ドメイン駆動設計）の優位性を説明
・サンプルシステムを開発した際のソース
※GitHubにアップロードする予定
では早速本題に入りたいと思います。
大規模システム移行における課題
・システム品質悪い、保守コスト膨大
企業の業務が大きくなればなるほど、仕様変更と機能追加が行われ、その際にスピードかつ低コストで要件が実現させたいですが、アーキテクチャーと各クラスの依存関係を考えずに実装されているため、各クラスが密結合になり、小さな仕様変更でも、修正するクラスが多くなります。さらに関連ドキュメントも古くなり、保守に膨大がコストが必要。
※最悪全システムをリファクタリングすることになる
・発生する根本原因＆自分の所感
企業が成長するために事業拡大は必然で、初回システムを開発する際は品質はいいものの、仕様変更と機能追加すればするほど品質落ちてしまいます。お客様の要望で開発しているシステムは我々システムエンジニア（SE）としては一つのプロジェクトかもしれませんが、お客様にとっては企業を支えるプロダクトです。
なので、プロダクトとして、開発しているシステムの未来性を見込み、今後のためにいかに低コストかつ高品質でシステム再構築するか、IT技術を持つSEが責任をもって提案するべきだと考えています。
そして、DDD（ドメイン駆動設計）がそれを解決するための道しるべとして挙げられます。
DDD（ドメイン駆動設計）の概要
・DDDとは？
概要： システムを設計する際の設計手法
良い点：
・開発時：業務分析したうえでモデリング手法（UML）で可視化することで、要件定義の際にお客様と合意を取りやすくなる、また、それをベースに詳細設計を行うことで、開発者に対してもシステムを理解したうえでの開発が可能で、品質が高くなる。
・システム改修時：既存モデルを更新し、業務を実現する際に低コストかつ高品質で改修できる。
・DDDを実践する際の流れ
⓪**（システム改修時のみ）既存システムのモデル資料を受領
①顧客の要件定義を聞き出す。
②ドメインモデリング（ドメイン、サブドメイン、コンテキストを設計）
※顧客と要件を用意するために、①②を繰り返す
③マイクロサービス設計（単一責任原則）
④ドメインモデルによるシステムモデリング（オブジェクト指向OOA/D、デザインパターン）
⑤ドメインモデルによるデータベースモデリング（エンティティ、値オブジェクト、集約を考慮）
⑥システムアーキテクチャー設計
※（システム規模が大きい場合）**Middle Platform（中国語では「中台」）を考慮する
⑦各モデルをもとに開発を行う
⑧CI/CDによるビルド、テスト、デプロイを自動化
・DDDが求められる能力
・業務モデリング（単一責任の原則を準拠、かつ現実視点で客観的に業務を分析して分割）
・オブジェクト指向（設計時には開放/閉鎖原則を準拠）
・デザインパターン（Decorator パターン、Factory Method パターン）
※貧血モデル と 充血モデルを考慮して設計
↑日本語でどう言うか分からないため、まずこのように翻訳します。
・システム設計（クラス図、ユースケース図、シーケンス図などのUMLの設計）
・データベースモデリング（NoSQLが推奨される）
・マイクロサービス（Spring cloudなど）
・システム(docker、k8s)、データベース（負荷分散）の高信頼・高性能設計
・アジャイル開発
・クラウド技術（AWS）
・CI/CD技術
・まとめ
以上、自分の理解でドメイン駆動設計についての概要、実践する際の流れと必要な能力をまとめました。