aya nakahara

生活について考えるブログ

DDDのAnticorruption Layer(腐敗防止層)パターンを理解する

この記事は、aratana Advent Calendar 2019 - Qiita の4日目の記事です。

昨日は、アラタナの創業者であるほまちゃん(https://qiita.com/issei-homan)の

ChromebookとAmazon WorkSpacesとCloud9で快適・セキュア・いつでもどこでも環境構築 - Qiitaでした!

 

アラタナアドベントカレンダー2019

 

こんにちは、12月でバックエンドエンジニア歴半年になった中原です。

今回は、新サービス開発にインプット0で望んだ結果、とんでもない設計/実装をしてしまった反省をしようと思います。失敗したけどDDDは楽しい!

 

 

TL;DR

  • Anticorruption Layerのおさらい
  • DDDのAnticorruption Layerを知らないまま開発にジョインしたら大変なことになった話(実際どんなことをやってしまったのかを晒す)
  • 今回の新サービス開発におけるAnticorruption LayerのプラクティスをDDDの本を眺めつつ振り返る

 

 

 

 Anticorruption Layerのおさらい

 

はじめに、組織的パターンというチームの関係性を示すパターンがあります。

1. パートナーシップ

両者の利害が一致しており、協力関係にある。

2. 別々の道

統合しないし関与しない。

3. 順応者

上流側が下流側の要望に応えない場合。

4. 顧客/供給者

上流側が下流側のサポートに応じる。

 

今回の開発は、3の上流側が下流側の要望に応えない場合でした。

この場合、順応者側が腐敗防止層(Anticorruption Layer)を用意して上流のモデルの変換処理を行う必要があります。

f:id:amy_____5:20191205013055p:plain

組織的パターン「順応者」のイメージ

 

新規に構築するアプリケーションも、たいていはレガシーなど既存の外部システムと連携しなければならない。既存システムが持つドメインモデルは、これから構築しようとする新しいドメインモデルにはそぐわないことが多い。両者のモデルの対応付けが容易でない場合は、新システムと既存システムとの間に隔離層(腐敗防止層)を設けて、そこで両方向に対するモデルの変換を実装して両者のモデルを完全に独立させてしまう。ただし、腐敗防止層の構築には大きなコストがかかるので注意。 

 

引用: 

[ 技術講座 ] Domain-Driven Designのエッセンス 第3回|オブジェクトの広場

 

 

 

 

実際どんなことをやってしまったのか

 

先ほどおさらいしたAnticorruption Layer(というかDDD自体)をそもそも深く学ぶ間も無く開発にジョインしました。

すると、上流者側や本来なら順応者となるべき下流側でもモデルをうまいこと変更して処理が通るような修正を入れてしまったのです..。もちろん変更差分も多かったです。

 

 

その際のレビュー内容が、今までのどの技術本よりも私の理解を進めてくれたので貼っておきます。神レビューです。

 

f:id:amy_____5:20191205014008p:plain

やさしいレビュー

 

 

 

ラクティスをDDDの本を眺めつつ振り返る

この本を眺めながら、振り返ります。

f:id:amy_____5:20191205021351j:plain

「実践ドメイン駆動設計」から学ぶDDDの実装入門

今回は、Anticorruption Layerに加え上流側に公開ホストサービス(Open Host Service)を使用し、2つの境界づけられたコンテキスト間のやり取りをするプロトコルとしてProtocol Buffersを用いました。

 

順応側のAnticorruption Layerでは、上流側のmodelを受けて変換処理を行いました。

さらに、受信だけでなく送信する際には順応側のモデルを一度プロトコルへ変換する機能も実装しました。

 

 

 

 

最後に

夜中の2時を回って力尽きたのでここまでとします。

おやすみなさい。