Closed6
2024-04-15 週の読んだ記事(チームトポロジー/モデリングと分割設計/仕様化テスト/品質特性/コンウェイの法則/ビジネスロジック)
ブシトラ4/15
-
顧客に「素早く」「頻繁に」「安定的に」価値を届ける。問題があれば素早く修正する
-
安定した早いフローを重視する
-
コンウェイの法則
- システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう
-
チームファースト
- 組織図やマトリクスに依存した組織構造では、素早いデリバリーやイノベーションは無理
- チームを増やすとコミュニケーションlinesが増えすぎて詰む
- 機能しているチームを長く保つのがいい。
-
認知負荷
- 課題内在性負荷
- 課題外在性負荷
続きはまた書く
ブシトラ4/16
ユーザーというのは、個人でも法人でもどうとでも解釈可能で、利用者のあらゆる側面を意味しているように見えてしまっています。Userクラスが、顧客管理クラスから見れば個人に見えるし、法人管理クラスからは法人に見えている。結果、利用者に関係するさまざまな概念を内包できてしまうわけです。
個人と法人では解決したい問題が違います。だから、ミクロなシステムとしては別です。解決したい問題によって扱う要素が違うと先ほど説明しました。個人では生年月日、法人では法人番号、各ミクロのシステムで必要とする情報が違うのに、一緒くたにしてしまっているんです。
- 関心の分離と分割統治 を行うこと
ブシトラ4/17
仕様化テストについて。仕様が曖昧ならふるまいから書いてしまえばいいじゃない か(心理負荷はあるが)
仕様化テストとは、コードの現在の振る舞いを確認するためのテストのことです。仕様化テストは、コードが実際にどのように振る舞っているかを明らかにします。自動化したテストでコードの振る舞いを確認できれば、システムを変更するときに、少なくとも変更していない部分の振る舞いが変化していないことをすぐに確認できます。
ブシトラ4/18
- システム・ソフトウェア製品における品質特性 について
ブシトラ4/19
- システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう
- 職能型の組織構造にすると、チーム内は密結合になり、チーム間は疎結合になる
- 職能型ではなくサービス型の組織構造にすることを逆コンウェイの法則という
ブシトラ4/21
-
ビジネスロジックとは アプリケーションをプレゼンテーション・ビジネスロジック・データアクセスの 3 つに分けたとき、「プレゼンテーションでもデータアクセスでもない部分がビジネスロジック」
-
トランザクションスクリプトパターン
- 「Service」クラスに処理を記述し、「DTO」をデータの入れ物としてやりとりします。
-
ドメインモデルパターン
- 処理とデータを一緒に配置するオブジェクト指向的な実装
このスクラップは10日前にクローズされました