アプリの設計にレイヤーを取り入れる前の問いかけ
メタ認知のための問いかけ
レイヤの存在意義を明確にする
なんの課題のために必要で、どうやってテストするか
説明や前提条件を客観的に行う
概要→具体の順を守る
結論に引きづられないように注意する
レイヤが欲しくなるというのは、チームが大きくなりすぎている前兆なのかもしれない
まず考えること
開発組織を十分に小さくする
機能単位で別プロダクトレベルに切り離す意識の構成にする
レイヤはほとんどケースでは開発者が恣意的に作り出したものということを自覚する
技術ドリブンでやらない
本質的な対象の性質を理解することと集合知を形成するためのコミュニケーションに投資する
「このレイヤはドメインの複雑さをどうSimpleに解決しようとしているのか？」
これが言語化できないならまだドメインの理解が足りない
実装をEasyにするレイヤは何も解決しない
オーバーエンジニアリング, カーゴカルトプログラミングにきをつける
長期的にROIを上回るのか？
データと振る舞いは切り離す
技術でき解決できることは限られており、大抵の場合はソフトウェアの外に問題がある
ドメインと技術基盤の乖離による冗長化や認知負荷増加
開発効率と理解容易性はトレードオフの関係にある
ゴリゴリのレイヤードアーキテクチャ
マッシュアップ系のサービスで外部依存がかなり多い、といったケースでは有用
単純なクラサバだとクライアントとサーバーの依存を切り離す旨味が少ない
実装に慣れていないジュニアへのレールとして
意味は成さない
あまりにも落とし穴(というか制約)が多い
基本的には「やるべきこと」よりも「やらないこと」を決めるほうが行動に繋がりやすい
いくつかシンプルな原則がある #設計原則
軽量DDDのようなDDDの技術的な側面だけに焦点を当てたものはアンチパターンだと思われる
モデリングやドメインと問題空間と解決空間をおざなりにしてはならない
変化に対する"想定外"や"考慮漏れ"が多発する
ドメインの変化を考慮していない
その時点のスナップショットとなるためスケール時に形骸化していく
その結果は責務が肥大化
不確実性に対する不安とどう向き合うか
自身の経験上は(特にフロントエンドは)改修がコードに閉じることは稀であり価値単位の改修になる
ユーザーにとっての振る舞いの変化こそが価値であり、前提条件が変わったら内部構造も変わる
制約や前提条件が変われば0から価値を見直して書き直す
不安をPRで管理する
アーキテクチャよりもPRや普段の思考、チームメンバの些細な意識変化に目を向ける
冷静に、落ち着いて考えよう
大事なのはレイヤーではなく、関心事の分離
パッケージングへ考えをダンプした