アーキテクチャを考える その1

要約すると...。

チームで一番スピードが出せる状態で、高凝集で疎結合であれば、
読み側、書く側の負担はそんなに高くないんじゃないかなーと思っている。

前提

• 事業だと、予算だったり収益を生み出さないといけないので、
  予算と品質のトレードオフがありますが、
  設計と実装の工期のバランスが崩れるので、
  基本的な品質レベルの担保向きです。
  好きにやれるのであれば、やっていいと思います。

• DDDやClean Architectureはあまり理解できていないので、
  自分は逆に教えて欲しいぐらいのレベルです。

アーキテクチャを考え直したきっかけ

自分で1度構成を考えてチーム内にレビューしてもらったものの、
作ってリリースしたのはいいものの、本当にこの構成って正しいんだっけ？
他の人が見たら、わかりにくいなーとかあるんじゃ？
という疑問が湧いてきたからです。

アーキテクチャが伝播するまで

いろんな参考記事だったり見ましたが、各会社でレイヤーの区分は一致していない印象でした。
まあ、結局、チーム内で共通認識を作る。ってことが大事なんだなあという印象ですね。

ただ、こうゆうことに興味がなくて機能ができればいいやーという人も中にはいるので、
そのスタンスの人がいる場合、ドキュメント作成のコストは高くなりますね。

何年かすると、最初にアーキテクチャを考えても、
退職や異動で作った人がいなくなり、構成は崩れていってしまうので、
ある程度縛れるようにしないといけないと思っているので、
難易度が高いアーキテクチャは採用しにくくなると思うんですよね。

(ここからは個人の主観です)
それと、アップデートの維持、拡張性だったりを考えると、
DDDライクな形にしておいて、ライトな形のパッケージ構成であれば
読み手、書き手の負担的には問題ないんじゃないかな？と思っています。

どこまで分割するべき？

普段はgo言語とphpを使っているので偏った意見にはなるのですが、

• 構造体、インターフェース部分から読む人
• ドメインの括りで読む人
  で分かれるのかなあと思っています。

僕はざっくり理解しているだけなので、ドメインで見てしまう感じです。
どちらが正解とかというわけではないとは思うんですけどね...。
ただ、どちらも許容できる状態であればいいのかなと思っていて、
凝集度の定義だったりは人によって異なるものだと思うので。

読む側、書く側の負担が高くなければっていうのと、
どんな書き方になっていれば慣れてもらえるか？だと思うので、

例 : ディレクトリ構成(参考程度に載せました)

├── application
│   ├── usecase
│   │   └── A_usecase.go
├── domain
│   ├── model
│   │   └── A_model.go
│   └── repository
│       └── A_repository.go
├── infrastructure
│   └── A_repository.go
├── interfaces
│   └── api
│       └── server
│             └── server.go
│       └── handler
│             └── A_handler.go
│	└── router
│	      └── route.go

まとめ

雑談っぽくなってしまいましたが、
どうゆう構成ならいいんだろう？というのはずっと悩んでいて、
正解が見えてないんですけど、
縛り過ぎて進まなくなってしまうことを避けたいなあと思って、

いろいろな方の意見を伺いたいなと思って、
現場でアーキテクチャを変えていった話とかあれば、ぜひ教えてください。