「実装の迷いを減らしたい」について
#パッケージング #設計 #設計原則 #プログラミング
from 誰が書いても同じコードというのは目指さない
関連
アーキテクチャ宇宙飛行士への疲労感と焦燥感
実はDDDってしっくりこないんです
良い設計の標準化やプログラミング能力の底上げに対する気持ちを残しておく
実装時の把握が楽になることや実装のブレを減らすことを目的としたレイヤを複数重ねても複雑性は減らない
モデルと開発者のメンタルモデルとの乖離を生む
認知負荷の高まりや依存関係増加によって複雑性は余計に高くなる
不確実性や複雑性は隠蔽するのではなく向き合い方を知るべし
スコープは小さいに越したことはないし、いいデータ構造はいいアルゴリズムを生む
アプリの設計にレイヤーを取り入れる前の問いかけ
Simple or Easy
Easyに逃げてはならない
フレームワークは思考を癒着させる
可読性、理解容易性、正しさへの迷いは作業者のバックグラウンドに依存する
実装能力やコミュニケーション不足など
慣れによって解決される部分もある
課題の分離
ジュニアへはミニマムなリファレンス実装を作る
「この通りに作れ」ではなく参考用
引き出しを増やすことを目指す
学習ハードルを下げる
自走してもらうための成功体験を作る
問題解決の引き出しは多いに越したことはない
解像度が高いと手段の多様性が生まれる
例えばバリデーションはおおまかに3種類に分類できる
1. 値に対するバリデーション(max, min)
2. 前提チェック, 相関チェック
3. エンティティに対する関係性の制限や制約なのか
これらの処理をどこでやるかを考える
コントローラ
サービス
モデル
戦略の失敗は戦術で補うことはできない
戦略を増やす
エンジニアリングにおいて抽象化とモデリングの違いは必要不可欠
依存関係をコントロールする術を身につけること
重要なことと重要ではないことを区別する
機能を構成に依存させない
共通化と抽象化
戦術を増やす
ドメイン以外のもの、を区別するための語彙や知識を増やす
制御の反転(IoC)
アプリケーションレイヤ
アプリケーションサービス, ドメインサービス
デザインパターン
引き出しの多さは実装の精度に直結する