Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
•Download as ODP, PDF•
42 likes•65,924 views
devfest tokyo 2017
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Similar to Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える (20)
More from pospome
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
- 7. なぜレイヤが必要なのか?
- 11. どういうレイヤ設計が適切なのか?
- 13. クリーンアーキテクチャ Entities Use Cases Controllers, Gateways, Presenters UI, DB, Web, Devices
- 20. レイヤ（ディレクトリ）構造 adapter handler presenter cmd presenter registry usecase input output domain model service repository infra dao mail adapter を置くこともあるが、 Webサーバ実装だと handler があれば事足りる事が多 いので、 最近は handler だけ置いて、 adapter 欲しくなったら adapter を置いている
- 24. 以下を保証できない実装になっていると レイヤ構造を導入した意味がない ・コードの依存関係を整理できる ・レイヤ間の差し替えを担保することができる ・レイヤ内のパッケージの凝集度を高めることができる
- 25. 実装する時に意識している点を紹介
- 29. レイヤには責務がある
- 30. handler ・HTTPを受け取り、usecase を呼び、結果を出力する ・結果は json だったり、HTML だったりする ・基本的に薄い実装になるが、 HTTPの body, header のパース処理など 場合によっては薄くならない可能性もある
- 31. usecase ・いわゆるアプリケーションレイヤ ・システム仕様上のユースケースを表現する ex. ユーザー登録、アイテム消費、チーム一覧表示 ・handler から呼び出される 1つの handler に対応する専用 usecase が1つ存在する ・基本的に domain を触る
- 32. domain ・いわゆるモデルレイヤ ・ドメイン（業務領域）に関する値と振る舞いを持つ ・他のレイヤに依存してはいけない ・DDDの実装パターン別に model, repository, service というパッケージが存在する
- 33. infra ・技術的関心事を扱うレイヤ ex. DB, Mail, MessageQueue ・直接 handler, usecase から呼ばれることもあるが、 基本的に domain の interface によって抽象化される
- 35. レイヤの責務 = 改修起点
- 36. ・HTTP POST が PUT に変わる →handler が起点 ・データ保存先が RDB から API になる →infra が起点 ・ユーザー登録後にメール送信する処理を追加する →model が起点
- 38. 責務があいまいだとどうなる?
- 40. type User struct { Name string Address string } func NewUser(r *http.Request) *User { //省略 } http.Request を元に User モデルを生成してしまうかも
- 42. HTTP を domain まで引き回してしまうと、 HTTP を触るコードが各レイヤに散ってしまう レイヤのコード量に応じて、 実装対象レイヤを変えるという謎実装になる可能性も
- 43. type User struct { Name string Address string } func NewUser(name, address string) *User { //省略 } domain で扱っても問題ない概念に依存させた方がいい
- 48. func AddUser(r *http.Request) error { //実装は省略するが、http.Request を触っている想定 } 例えば usecase の引数で http.Request を受け取ってる場合に
- 49. デバッグツール用の コマンドラインツール でも usecase を利用したいと思ったら???
- 51. func AddUser(r *http.Request) error { //実装は省略するが、http.Request を触っている想定 } cmd で http.Request を生成する必要がある わざわざ http.Request を生成するのは不自然では? usecase が暗黙的に handler に依存している証拠
- 52. func AddUser(i input.AddUser) error { //実装は省略する } 個人的に usecase の引数は専用の struct にする
- 53. package input type UserAdd struct { Name string Address string TEL string } func (u *UserAdd) CreateUser() (*model.User, error) { //Userモデルを生成する } input struct は可能な限り外部レイヤに依存しない値にする モデルを生成するメソッドも生やす
- 54. package input type UserAdd struct { User *model.User } usecase に戻り値がある場合、 同じような理由で専用の struct を用意する 戻り値の struct はモデルを格納するだけの DTO
- 56. ちなみに input, output 用の struct は interface にしません 具体的な struct に依存させるようにしています ・外部レイヤに影響されない実装が前提 影響されるのであれば、実装が間違っている ・振る舞いに着目し、抽象化するものでもない 実装差し替えは不要 過度な抽象化はしない
- 57. handler が扱う HTTP という概念に usecase が依存しているのが原因で レイヤがレイヤとして機能していなかった 標準パッケージに依存しているコードは 一見問題ないように思えてしまうことがあるが、 そんなことはない
- 61. type UserTable interface { Get(id int) *model.User Add(u *model.User) *model.User Update(u *model.User) *model.User Remove(id int) *model.User } 例えば、ユーザーの CRUD を表現する interface 一見問題なさそう?
- 62. type UserTable interface { Get(id int) *model.User Add(u *model.User) *model.User Update(u *model.User) *model.User Remove(id int) *model.User } UserTable = RDBの概念? 実装が RDB から変更されると interface 名を修正する? interface の実装内で memcache とか叩けない?
- 63. interface によって抽象を扱うはずが、 命名が具体的なためにいまいち抽象とし扱いきれていない この interface が扱っている抽象は RDBにおけるCRUDの実装であって、 CRUD自体を抽象として扱っているわけではない
- 64. 仮に RDB の CRUD 実装のみを抽象化する目的であれば、 この interface 粒度でも問題ない ex. MySQL → PostgreSQL
- 65. type UserRepository interface { Get(id int) *model.User Add(u *model.User) *model.User Update(u *model.User) *model.User Remove(id int) *model.User } 抽象的な Repository という命名に変更する CRUD できれば実装は何でもいい
- 66. type UserRepository interface { Get(con *db.Con, id int) *model.User } interface の引数、戻り値にも注意 例えば、引数にRDBのコネクションを渡してしまうと、 interface とRDBの結合度が高くなる ・interface を実装する struct に持たせる ・実装内に持たせる ＊とはいえ、引数とか戻り値は特定の技術に依存してしまうこともあるのでな かなか面倒だったりする。
- 67. 以下に気をつけることでinterface の安定度が増し、 interface を利用するコードは変更に強くなる ・interface の命名粒度 ・interface の引数と戻り値 ＊変更に強くなるだけで変更不要になるわけではない
- 69. おまけ
- 71. 技術的関心事を interface として扱うのであれば、 具体的な命名は避けた方がいい SendGrid interface -> Mail interface
- 72. レイヤ（ディレクトリ）構造 handler presenter usecase input output domain model service repository registry infra dao mail service or infra に interface を置く 細かい説明は省略 repository 以外の技術的関心事も 忘れないようにした方がいいよというお話
- 73. おまけ
- 74. infra で発生する error を そのままハンドリングするのはやめた方がいい
- 75. package dao type User struct { } func (user *User) Get(id int) (*model.User, error) { return memcache.Get(id) } memcache にアクセスする DAO のコード これだけだと問題なさそう
- 76. func GetUser(id int) (*model.User, error) { u, err := dao.User{}.Get(id) if err == memcache.ErrCacheMiss { } } DAOを利用する側のコードが memcache のエラーに依存してしまっている interface 上は error で抽象化されているが、 利用する側のコードで依存してしまうこともあるので注意
- 77. package dao type User struct { } func (user *User) Get(id int) (*model.User, error) { u, err := memcache.Get(id) if err == memcache.ErrCacheMiss { return domain.ErrNoSuchModel } } アプリケーション独自の error でラップすればOK
- 78. 独自 error の定義で気をつける点は以下 ・error を捕捉するレイヤにとって問題ない抽象度にする 独自例外で ErrMemcache 的なやつを 再定義しても意味がない ・各レイヤの責務ごとに適切な error を考える ・ラップする必要のない error はラップしない
- 81. type UserRepository interface { Get(id int) *model.User } UserRepository（interface）と・・・
- 82. package dao type User struct { } func (user *User) Get(id int) *model.User { } UserRepository（interface）の実装をどこに置く?
- 84. handler infra を domain に依存させている usecase domain infra
- 85. interfaceと実装を domain に置く場合 ・実装が domain に存在するので、 MySQL を WebAPI にするという変更で domain に修正が必要になる ・domain は業務領域に関するコードを置くレイヤなので、 MySQL が業務領域に関するものでない限り、 domain に修正が入るのはおかしい 修正は infra に閉じられるべき ・実装が infra に存在すれば、これを回避できる
- 86. interfaceと実装を infra に置く場合 ・システム仕様に「ユーザー削除」が追加されると、 infra に修正が必要になる ・業務領域に関するコードを置くレイヤである domain に 影響がない ・本来であれば、domain に修正影響が発生し、 その影響が infra に伝搬するはず ・interface が domain に存在すれば、これを回避できる
- 87. レイヤの責務を考慮すると、 interface は domain に置き、 実装は infra に置くことになる
- 88. ただし、 interface、実装共に infra に置く場合もあるし、 interface すら用意しない場合もある なかなか難しいところ レイヤの責務と抽象の必要性を考慮して 一貫性を持った実装方針であれば問題ないはず
- 90. infra に実装を置き、domain に interface を置き、 実際に usecase から interface を利用してみる interface と実装を結びつけるために registry を利用する
- 92. package registry type Repository interface { NewUser() reposiroty.User } type repositoryImpl struct { } func NewRepository() Repository { return &repositoryImpl{} } //引数は interface だが、戻り値は実装になっている func (r *repositoryImpl) NewUser() reposiroty.User { return &dao.User{} } repository 用の registry で 各種 repository を取得できる registry 自体を interface にする ことで、テスト時に必要なメ ソッドだけ実装すればいい service 用の registry もある
- 94. メソッド名で取得対象の repository を明示できるのも利点 実装の関係上、 以下のような Master, Slave の使い分けが必要な場合に役立つ package registry func (r *repositoryImpl) NewUserMaster() reposiroty.User { return &dao.User{“master”} } func (r *repositoryImpl) NewUserSlave() reposiroty.User { return &dao.User{“slave”} }
- 95. 具体的な実装を紹介
- 96. package handler type User struct { repo registry.Repository } func NewUser(repo registry.Repository) *User { return &User{repo} } func (u *User) Add(w http.ResponseWriter, r *http.Request) { userRepo := u.repo.NewUser() userUsecase := usecase.NewUser(userRepo) } handler は registry を持ち、 registry から repository を取得することができる 取得した repository は usecase にセットする
- 97. package main func init() { repo := registry.NewRepository() userHandler := handler.NewUser(repo) http.HandleFunc("/add", userHandler.Add()) } handler の registry は main でセットする ＊GAEのコードなので、純粋なGo実装とは main の書き方が異なります
- 98. package usecase type User struct { userRepo repository.User } func NewUser(u repository.User) *User { return &User{u} } func (user *User) Add() *output.UserAdd { // repository の Add() を呼ぶことができる user.userRepo.Add() } usecase は repository を持つ registry を持たない
- 99. handler handler は registry に依存し、 registry は infra に依存している usecase domain infra registry
- 100. package usecase type User struct { userRepo repository.User } func NewUser(u repository.User) *User { return &User{u} } func (user *User) Add() *output.UserAdd { // repository の Add() を呼ぶことができる user.userRepo.Add() } なぜ usecase は registry を持たない????
- 101. usecase が registry を持つと usecase が依存する repository, service が大きくなってしまう 依存が明確ではなくなってしまう usecase は処理の流れを表現するので、 サービスロケータに依存させたくない
- 102. package handler type User struct { repo registry.Repository } func NewUser(repo registry.Repository) *User { return &User{repo} } func (u *User) Add(w http.ResponseWriter, r *http.Request) { userRepo := u.repo.NewUser() userUsecase := usecase.NewUser(userRepo) } なぜ handler は registry を持つのか?
- 103. 本来であれば、具体的な repository, service を DIする方がいーとは思うけど handler は domain に依存しないので、 registry に依存させても問題なさそう usecase で利用する repository, service に引っ張られて main & handlerを修正するのが面倒 要は実害なさそうだし、 面倒だから registry を突っ込んでる
- 104. こんな感じで infra の実装と domain の interface を 紐付けています
- 105. おまけ
- 106. package usecase type User struct { userRepo repository.User } func NewUser(u repository.User) *User { return &User{u} } func (user *User) Add() *output.UserAdd { // repository の Add() を呼ぶことができる user.userRepo.Add() } 以下の実装だと、 User の CRUD を User struct に紐付ける感じになり、 User struct が持つ repository, service が肥大化しそうなので、 input struct に持たせよーかなと思ってる
- 109. レイヤ実装は予想以上に難易度が高い
- 115. まとめ
- 119. おわり
Editor's Notes
- 発表する前にということですが、 1つ目、DDD関係ない内容ですが、 僕がDDD好きなこともあって、 若干DDDの概念が出てきます 2つ目、僕はマサカリ歓迎するタイプでして、 批判ツイートいただけると勉強になるので 是非マサカリ投げて下さい 3つ目、スライドは文字多めにしているので、 後から見返せるようにしています
- 目次こんな感じです
- では、進めていきます
- レイヤを言葉で表現すると、コードを性質別に分けるモジュール戦略だと思っています 最近だとクリーンアーキテクチャとかネットでよく見るので、サーバサイドとか golang とか関係なく、アプリケーションエンジニアであれば、皆さんご存知かと思います
- 説明するまでもないと思うんですが、 依存関係を整理できる 凝集度を高めることができるからですね
- つまり、システムの保守性が低下しないようにするためのアプローチだと思っています 2:00 5分伸びても大丈夫
- では、次に行きます
- で、結局どうすればいいの? って最初に考えると思います レイヤってたくさんあるんですよね
- あとは オニオンアーキテクチャ IODAアーキテクチャ なんてのもあります
- ただ、個人的にどれも大体同じなので、悩まなくていーかなと思っています
- なぜかというと、 結局、以下の3つは担保されるからですね。 レイヤとして最低限必要なポイントは抑えることができます。
- 図にするとこんな感じです handler, usecase, domain, infra があります
- これがディレクトリ構造で レイヤアーキテクチャがベースです
- こんな感じで handler 上位に adapter を置くこともあるんですけど、 面倒なのであんまりやってないですね
- ということで、 僕のレイヤ構造を紹介したんですけど、 ネット上の記事を見ると、 大体同じ感じになるので、 レイヤ設計自体には、あまり悩まないと思います
- 今更「クリーンアーキテクチャとは?」みたいなことを僕が説明しても、他の記事見た方が早いので、 今日は説明しません 一歩実装に踏み込んだ話をしようと思います 5:00
- レイヤ内実装が今日のメインです
- 最初にレイヤのメリットを説明したと思うのですが、 実装によっては、このメリットを失ってしまう可能性があります
- なので、今日はこのメリットを失わないために意識している点を紹介します
- こんな感じで紹介していきます。 今回の発表では具体的なコードベースでレイヤ設計における実装を丸っと紹介しようと思ったんですけど、レイヤのルールを理解しなければ、「なぜそういうコードになるのか?」という意図が伝わらないと思いました。 なので、今回はレイヤ内実装といいつつも、若干抽象的なレイヤにおけるルールを紹介していこうと思います。
- では、1つ目 「レイヤ責務と改修起点とレイヤで扱う概念」についてです。
- これは先ほど紹介した僕が採用しているレイヤ構造です。 これをベースに説明していきます。
- 当然ながらレイヤには責務があります ということで、僕のレイヤにおける責務をザックリ説明します。
- handler は単純ですね。 基本的にHTTPを触って、usecase を呼んで、その戻り値を結果として出力します。 基本的に薄い実装になるんですけど、場合によっては複雑になったりします。
- 次は usecase レイヤ。 これはいわゆるアプリケーションレイヤで、 命名はクリーンアーキテクチャから取りました。 アプリケーションっていう表現よりも、ユースケースって表現の方がしっくりくるので、こういった命名にしています。 責務としては、ドメインを触って仕様上のユースケースを実行するだけです。 特徴は handler と1対1になることです。
- 次はドメインレイヤですね。 いわゆるモデルを置くところでしょうか。 このレイヤの実装が保守性に大きく左右されます。反面、説明するのが難しいので、今回の発表ではほぼ取り上げません。
- 最後がインフラレイヤです。 ここは技術的関心事と呼ばれるコード群を置くところで、DBアクセスだったり、メール送信の具体的なロジックを配置します。
- ということで、ザックリまとめるとこんな感じです。 handler, usecase, domain , infra それぞれのレイヤに責務があります。
- そして、レイヤの責務は改修起点でもあります
- 例えば、HTTP POST が PUT に変わった場合は handler が改修起点になります その他も同様に改修起点が決まっています
- この図の矢印は各レイヤの依存方向を簡単に表しているのですが、 例えば、handler が改修起点になった場合、他のレイヤに修正が及ぶことはないです。 domain が改修起点になった場合、それに依存している全てのレイヤに修正が及ぶ可能性があります。 こう見ると、「domain が改修起点になると、影響が大きすぎる」と思うかもしれないですが、domain はシステム仕様そのものなので、一番影響力があって当たり前です。 そもそもレイヤ同士の依存を完全になくすことは不可能なので、「どこに影響があると、どこが変化するのか?」を自然な形に保つことしかできません。 そう考えると、この依存関係自体は妥当であると思います。
- では、責務があいまいだとどうなるでしょう?
- そうすると、本来 handler で完結するはずの改修が全レイヤに影響することになるかもしれません せっかくレイヤを導入したのに、全レイヤが改修対象になりえるのであれば、fat controller と変わりません。 なんとなーく分けてみたって感じですかね。
- そして、さらに、domain が HTTP を触ってしまうと、どのレイヤでも HTTP を触ることができてしまいます。 「どのレイヤでもHTTPを触っていい」という状況になると「usecase にこれ以上ロジック書きたくないから domein に書こう」というコード量に依存した実装になってしまう可能性があり、レイヤの責務が破綻していきます。
- じゃあ、どうするかというと、 string に依存させます。 domain 内で定義されている struct があれば、それに依存させても大丈夫です。
- ということで、 レイヤの責務を明確化し、 レイヤ内で触る概念を見極める必要があります。 11:30
- 次が２つ目「レイヤ間の実装差し替え」です。
- なので、この図でいうと、handler が他の何かに変わっても、usecase は影響を受けないはずです。
- 図で言うとこんな感じですね
- で、どうなるかというと、 http 関係ないコマンドラインツール で http.Request を生成する必要があるんですよ これって不自然ですよね? これは暗黙的に handler に依存していることになります。
- じゃあ、どーするのかというと、 個人的には専用の input struct を定義して、 それを引数にしています
- input struct は可能な限り外部レイヤの影響を受けない値で構成させます。 今回の例でいうと string で構成されています。 そして、モデルを生成するメソッドも実装しています。 このメソッドを実装するかどうかは好みですね。直接 usecase で input struct の値を触って、モデルを生成してもいーと思います。 usecase の引数は struct ではなく、string, int というプリミティブ型でもいーんですけど、引数が増えると面倒なので、struct にしています
- 戻り値も同じように専用の struct を作ります。 ここは意見が別れるところでもあるのですが、フィールドにはモデルを持たせています。 例えば、ユーザー登録の usecase の戻り値であれば、登録された User モデルのみ structに含めますし、 ユーザー一覧の usecase であれば、User モデルの配列や表示上必要になるフラグも含めます。
- なので、ディレクトリ構造には input, output が存在します。 時間足りなくなるので、細かくは説明しません。
- ちなみにですが、 input, output の struct は interface として定義しません。 これは抽象化が不要認識だからです。 依存させても問題ない実装にすべきだと考えています。
- ということで、 レイヤ間の差し替えを意識して引数、戻り値を定義しましょう。 標準パッケージに依存してるからOKとかではないです。 15:00
- 次で3つ目ですね。 「infraを抽象として扱う」です。
- DBアクセスなどの infra を interface で抽象化するテクニックは有名だと思っています。 機械的に適用できるパターンなので、 今更説明するまでもないと思っています。
- ただ、いくつかポイントがあってですね、interface が表現する対象の抽象度がそれに当たります。
- 例えば、ユーザーの CRUD を表現する interface これでも動作はするのですが・・・
- interface 名に table って付いちゃってるんですよね。 table って RDB の概念じゃないですか。 RDB から NoSQL になったら interface 名って変更するんですかね? RDBを抽象化した interface の実装内で、memcache とかのキャッシュにアクセスしていーんですかね?
- この例だと、あくまで RDB の実装を抽象化しているだけなので、いまいち抽象として機能してない感がある。
- 仮に、MySQL から ポスグレへの実装差し替えのみ想定して定義したのであれば、正当性があるのですが、 それって抽象として表現する粒度が細かいと思いませんか?
- じゃあ、どーすればいいかというと、Repository という抽象的な単語に差し替えます。 で、単語は別に DAO とかでもいーです。好きなやつにしてください。
- あと、引数、戻り値にも注意した方がいーですね。 RDBのコネクションとか持つと、結局依存してしまいます。 ただ、ここらへんをちゃんとやるのはなかなか面倒だったりするので、適度な妥協は必要です。
- ということで、interface の命名粒度と引数、戻り値に気を付けましょう。
- ネット上の interface による抽象化の記事ではテストがフォーカスされているが、 抽象として扱う以上、より適切な抽象粒度を選択する必要があります。
- で、おまけがあってですね・・・
- モデルの CRUD 以外の抽象って、忘れられている感じがするんですよね。 例えば、メールとかですね。
- モデルの CRUD 以外もちゃんと抽象化してあげた方がいーです。 メッセージ・キューとかメールですね。
- で、僕はモデルの CRUD 以外の技術的な interface は service もしくは infra っていうパッケージに置いています。 今回は説明してる時間ないので、 Repository 以外も考えた方がいーよってことが伝わればいーかなと思います。
- さらにおまけがあってですね・・・
- 21:00
- そして、4つ目は「infraの抽象とレイヤ構造」です。
- 先ほどの発表で interface について話したと思うんですけど、 その interface と、実装のですね、 レイヤ構造における置き場所を考えないとレイヤの責務があいまいになります。
- interface は先ほどお話した Repository で、
- 実装は interface を実装したものですね。 で、これをどこに置くのかと・・・
- 結論からいうと、domain に interface を置いて、 infra に実装を置きます
- つまり、infra を domain に依存させています。
- 仮に、interface と実装の両方を domain に置く場合、 技術的な改修で domain レイヤが影響を受けます。 domain レイヤは業務領域に関するロジックを持つレイヤなので、 技術的な改修で影響を受けるのは不自然です。 実装を infra に置くことで、これを回避できます
- 仮に、interface と実装の両方を infra に置く場合ですが、 システム仕様上、モデルの CRUD に関する仕様変更があった時に、infra しか影響を受けないことになります。 モデルの CRUD というシステムのコアな仕様を infra が握っていることになるので、 これも不自然ですね。 interface を domain に置けば、回避できます。
- ということで、 interface は domain に置き、 実装は infra に置いています。
- 24:40
- 「infra 実装の DI 」についてです。
- 先ほど技術的関心事に関するコードは interface を domain に置き、実装は infra に置くと説明しましたが、それらを紐付ける仕組みが必要です。 そのために registry という仕組みを利用しています。
- このように registry というディレクトリありますね。
- registry は repository, service を生成する factory object で、戻り値が domain の interface になっており、実際に return するのは infra の実装です。
- 僕は repository, service の2つで分けています。
- registry の目的としては interface と実装の紐付けなんですが、 具体的にどのような repository, service を取得するのかをメソッド名で明示できる利点もあります。 例えば、ソーシャルゲームだと、ユーザーが持っている課金周りのデータはスレーブ遅延の影響を受けないようにマスターから取得したいというケースがあります。
- ということで、registry の使い方をコードベースで説明します。
- まず、handler は registry を持ちます。 そして、registry から usecase に必要となる repository, service を選択して、usecase にセットします。
- hanlder の registry は main でセットします。
- そして、usecase は domain レイヤで定義されている repository, service を持つので、任意のタイミングでそれらを叩くことができます。
- つまり、registry, handler, infra で依存関係が生まれます。
- usecase は直接 domain を触るので、 依存関係をはっきりさせておきたいからです。 サービスロケータとして registry を持つと、 依存関係が大きくなりすぎてしまう。
- 直接 repository, service を触るようなレイヤでもないし、usecase が必要とする repository, service に引っ張られて handler を修正するのが面倒だからですね。 本来であれば、repository, service にちゃんと依存させた方がいーですね。
- ということで、こんな感じです。
- usecase の struct に repositoy, service を持たせると、メソッドが増えていくたびに必要となる repository, seriviceが増えていくので、結局メソッドと struct のフィールドの依存関係が整理できていない感じがするんですよ。 なので、input 用の struct にそれらを持たせて、usecase は関数にした方がいーかなと思っています。 30:00
- 最後は「レイヤの必要性」についてです
- みなさんは今まで説明してきたポイントを考えながらレイヤ実装していますか?
- 意外かもしれないですが、レイヤ実装は難易度が高いです。 僕はこういったレイヤ構造に関する知識があるので、他人が考えたオレオレレイヤ構造のように自分が知らないレイヤでも、それに合わせてコードを書くことができると思っているのですが、みんながみんなそーではないという認識を持った方がいい。 そして、そういった人たちからすると、レイヤ構造は単なる複雑なアーキテクチャになる可能性があります。
- そして、システム仕様、規模によっては、同じように単なる複雑なアーキテクチャになってしまう可能性があります。
- あとから改修はなかなか上手くいかないと思いますね。 この中でいうと、密結合はあるあるですね。 あと、既存コードを把握できてなくて、触れない、触りたくないというのもありますね。 新規コードのみレイヤ構造を導入っていうのもアリなんですけど、人によっては統一感を重視したいという意見もあるので、これもなかなか難しいですね。
- そもそも、レイヤの必要性って色々な要素に左右されるので、適切な選択は無理なのかなーと最近思っています。
- 33:00 ここは少し戻って説明してもいーかも
- 今日は限られた時間のなかで可能な限りレイヤ設計におけるルールを紹介しました。 そして、時間が足りないので、 正確に説明できなかった箇所もあります。 とはいえ、参考にしても問題ない内容にできたかなーとは思います。