Skill.md検索

ビジネスロジックを「事前条件・事後条件・不変条件」として宣言的に記述し、自動検証できるようになります。複雑なドメインルールをコード化する手間が大幅に削減されます。 集約のライフサイクル全体を不変オブジェクト（readonly）で安全に管理でき、状態遷移のバグを防げます。 Property-Based Testing（自動テスト手法）を使って、手作業では見つけにくい例外ケースを自動発見できます。 フレームワークに依存しない純粋なビジネスロジックを実装でき、将来のフレームワーク変更時もコードを再利用できます。 エラーハンドリングが例外ではなくResult型（成功/失敗の型安全な表現）になり、予期しないクラッシュが減ります。 ドメイン駆動設計（DDD）でビジネスロジックをきちんと整理したいエンジニア 複雑なビジネスルール検証の自動化テストを減らしたい開発チーム TypeScriptで型安全性を重視するプロジェクト 集約（エンティティ）の状態管理がメインのシステム seizu は、ドメイン駆動設計のビジネスロジックをコントラクト（事前条件・事後条件・不変条件）として宣言的に記述し、Property-Based Testing で自動検証するTypeScript ライブラリです。クリーンアーキテクチャのドメイン層（最内周）に位置し、フレームワークやインフラに一切依存しない純粋なビジネスルール表現に特化します。集約の状態は readonly な plain object で表現し、すべての操作は Result を返す Railway Oriented プログラミングを実践します。基本インポートは define, guard, check, ensure, ok, err, pass, isOk, isErr, map, flatMap, match など。実装はStep1で集約の状態を readonly plain object で定義、Step2でドメインエラーを tagged union で表現、Step3で define() でコントラクトを宣言するフローで進められます。

ユースケース中心のシナリオテスト設計:「ユーザーが実現したいこと」を Given-When-Then 形式で記述し、実装より先にテストを設計することで、要件を正確に把握できます。 実装の品質を事前に担保: テスト駆動で開発することで、バグの早期発見、設計の問題点を実装前に気づき、手戻りや後付けの修正を減らします。 ドメイン言語でテストを記述: 技術的な詳細ではなく、ビジネスロジックの観点でテストを書くため、非エンジニアも仕様書として読むことができます。 内部実装を変えずにリファクタリング（コードの整理・改善）が可能: 外部動作（振る舞い）が変わらなければテストは通り、安心して内部実装を改善できます。 Event Sourcing・CQRS との親和性: イベント駆動設計を自然にテストでき、複雑なビジネスロジックの正確性を検証できます。 業務ロジックが複雑で、バグのリスクが高いプロダクト開発チーム 長期保守が必要なシステムの設計・開発を担当するエンジニア テストをドキュメント・仕様書として活用したい開発チーム Event Sourcing や CQRS などの先進的なアーキテクチャを採用する組織

認知負荷を下げたUIコンポーネント設計: 認知心理学の原則（親近性バイアス、段階的開示など）を適用し、ユーザーが迷わず、理解しやすいインターフェースを設計できます。 ストレスのないユーザーフロー設計: Doherty 閾値（0.4秒以下の応答時間）や最適化フィードバック（ローディング表示、Optimistic Update など）で、待ち時間のストレスを軽減します。 ユーザーの心理状態に合わせた情報設計: 初心者には親切に、経験者には効率的に。Progressive Disclosure（段階的開示）やデフォルト値の活用で、すべてのユーザーが快適に使えるUI を実現します。 フォーム・入力インターフェースの最適化: エラーメッセージの配置、必須項目の指定、Decoy Effect（おとり効果）を活用した選択肢設計で、ユーザーの入力ミスを減らします。 美的ユーザビリティ効果による満足度向上: 統一されたデザインシステムと配色が、実際の操作性以上に「使いやすい」という心理的効果を生み出します。 Webアプリケーション・モバイルアプリのUIデザインを担当するデザイナー ユーザー満足度を高めたい プロダクトマネージャー・PO フロントエンド開発時に心理学的な根拠に基づいた設計をしたい開発者 既存UIの使いやすさに課題を感じ、改善案を検討している企画・営業チーム