この記事はWHITEPLUS Advent Calendar 2018 最終日になります。

こんにちは、初日以来の登場の 森谷 です。 初日にはホワイトプラスを支えるエンジニアの環境や開発スタイルという記事で働く環境や開発スタイルを中心に書きまして、

具体的にどんなシステムを開発しているのかは、最終日に可能な限り書いて見ようとおもいます。

と書いてしまったが故に、泣く泣く 書いたので張り切って筆を取ってみました！

TL;DR.

この記事で分かること

• リネットにおける現状のコンテキストマップ
• 現実的な範囲で何をしているか

この記事で分からないこと（いつか世に解き放ってみたい）

• なぜコンテキストマップを整理するに至ったのか
• どうやってコンテキストマップを整理したのか

あらためましてDDDとは

Advent Calendarが弊社内にも展開されることから、 はじめにDDDとは何者なのか？と軽く説明していきたいと思いましたが、 やはり偉大な先人がわかりやすい説明を書いてくれておりましたので、 引用させていただきまして。

実際の業務をきちんと理解しないで作ったら、リリースしてもあんまり使われなかったり不評なものができる
きちんと整理されてないプログラムを書いたら、あとから修正するのがどんどん大変になる

当たり前と言えば当たり前ですが、更に言い換えると、

1. 使われるシステムを作るため
2. 使われ続けるシステムになった場合、継続してメンテナンスが可能な状態にするため

というあたりが、DDDの目指すところになるのではないでしょうか。 （言葉にすると単純ですが、これを実現するのがどれだけ難しいか…）

リネットにおける現状のコンテキストマップ

の前に前提としては、同じリネットの冠は付くのですが、 リネットは扱う商品により4つのサービスに分かれております。

この4つのサービスを支えるシステム群が、 モノリシックな構造のままサービスの成長とともに規模が大きくなり、 現状はこのようになっています。 （胸を張れたものではありませんが、敢えてありのままを出してみるということで…）

補足として、

• オレンジの実線が外部連携
• オレンジの破線がAPI
• 赤の枠線内がモノリシックな構造

となっており、要するに赤枠内が1つのリポジトリに収まってしまっている状態です。

程度の差はあれど、かれこれ10年ほど運用されているシステムになりまして、 他サービスでもこのぐらいの歴を重ねると、モノリシックな構造のまま、 運用されているシステムも世の中には、ままあるのではないかと思います。

理想は疎な構造のまま、開発され続けることだと思いますが、 現実は現実ですので、まずは正しく現実と向き合い、 現実的な範囲で粘り強く疎にしていく姿勢が大事なのではないかと思っている今日この頃です。

現実的な範囲で何をしているか

具体的に、どうやってどういう単位でリポジトリ分割していくかについては、 19年に入って徐々に模索していきたいと思っています。

が、出来る部分は進めており、 初日のアドベントカレンダーで紹介したように、

@akaimo 中心にGKE環境へ移行したり。

blog.wh-plus.co.jp

@ngmy により、CI環境の高速化を進めたり。

リネットのPHPアプリケーションのCIを10倍速くするためにやったこと - Qiita

外堀を固め、機が来たら動きやすいように整えています。

なので

19年は、外堀が良い感じで埋まってきていることを期待しつつ、 リポジトリ分割に手をつけられたらなと思っています。（来年のアドベントカレンダーではそのへんを書けたら〜と願いを込めつつ）

なのでホワイトプラスでは、マイクロサービス化を一緒に進めていってくれるエンジニアを募集しております。