パッケージング
#設計
おおまかに分けて以下のどちらかで、どちらも一長一短
技術駆動パッケージング
機能単位パッケージング
koushisa.iconの考え方
規模が大きくなる過程で見える視点を大切にする
安易にパターン化しない
フレームワークは思考を癒着させる
どうでもいいことは流行に従い、重大なことは標準に従い、ドメインのことは自ら設計する
誰が書いても同じコードというのは目指さない
考えながら作る(Write code thinking)
実装
React(≒Dan Abramov), コロケーション, Elmの哲学を意識してる
ReactなどのGUI開発に対応したスケーラブルなファイル構造
パッケージングについては主語->動詞->目的語(SVO)の順番で凝集度を高める
外部から観測可能(public)な振る舞いは利用者のメンタルモデルに合わせて、オブジェクト指向的に作る
プログラム以外にもあらゆる観点でメンタルモデルと一致した状態を目指す
実装詳細(private)については動詞を起点にすることもある
イメージ: SVO型のパッケージングで機能的凝集を目指すオニオンアーキテクチャ
メモ
Webアプリケーション設計の第一歩はディレクトリの整理から - Encraft 1
「責務」や「目的」については作る対象への理解が進んだときにはじめて分割を検討する
「対象」というのはドメインやエンティティのこと
アプリの内側の技術ではなく外側の概念
UI/UX, リソースの階層など
ユーザー中心設計フロー
理解を重ねながら段階的に小さく作る
1. ドメイン理解に時間をかける
2. 登場人物とその関係性を洗い出す
3. データ構造を検討する
4. そこではじめて構成を考える
5. 納得が行かないならまた最初からやり直す
一気に全部やらない
型にはめずに段階的に作ることを心がける
フレームワークは思考を癒着させる
プログラム以外にもあらゆる観点でメンタルモデルと一致した状態を目指す
実装<->ドメインの反復とモデリング
→ステークホルダとフィードバックしあえるする仕組みを作っておく
アジャイルな要件定義と開発スコープ
最初が一項目だったとしても関心の成長軸を作っておき、変化の際に既存の構造を変更せずに"追加"で対処できる構成を目指す
/mrsekut-p/モデルを中心に据えてDomain Expertと議論する