はてなブックマーク

ユースケースとは システムの外側の要求と、対する内側の応答を示すもの eg. "ユーザーの操作" に対する "一連の処理" 正常系（基本コース）と異常系（代替コース）からなる これをモデリングする。 なんのためにやるの？ ユーザーがシステムで何をしたいのか、何を得たいのかを明確にする システムができること、できないことを明確にする ほかにもいいことが エンジニア以外でも読めるので、システムイメージを共有しやすい 単体テストのケースを考える助けとなる 各ドメインの処理や流れがわかり、ドメインモデルの漏れや誤りに気づける 具体的には何をやるの？ ユースケース記述を書く ユースケース図（UML）を書く ユースケース記述 ユースケースを表や文章で示したもの 1つのユースケースについて詳しく書ける 例.1 めっちゃ詳しく書く場合の表 ユースケース記述の作成より 例.2 簡易版の表 初歩のUML：顧客

こんにちは。テプコンの声はフット岩尾だそうですよ、でおなじみputanです。 Hooks周り（v16.8.2現在）について、自分の開発チーム向けにまとめたいと思います。 ざっくりQ&A Q. Reactが大きく変わるって本当？ A. Yes、クラスコンポーネントから関数コンポーネントがメインになる。 Q. クラスじゃないならライフサイクルメソッドはどうすればいいの？ A. 代わりにHooksという関数群が用意されている。 Q. 今すぐ移行しないとダメなの？ A. No、しばらくは新しい機能が追加されるだけなので、これまで通り使える。 Q. Hooks使うと何かいいことあるの？ A. 再利用性の高いコンポーネントが作れる。同じ機能でもスッキリ記述できる。 関数コンポーネントがメインになる 関数コンポーネント＋状態管理関数群の形を取ることで、状態管理を含むコンポーネントでも再利用性の高いものを

前回：ぼくのかんがえたさいきょうのReact+Redux+CleanArchitecture 前回のさいきょうパターンの検証結果 まずは前回のさいきょうパターンですが、会社内の勉強会で実装を進めて行ったところ、少し整理されてこのようになりました。 Entity（図中model）はExternal層で使えるようにImmutable.jsのRecordを使って実装 ReadOnly、副作用NGという意図 ○ React+Redux的には使いやすかった × mutateメソッドで複製が作れてしまうため、"見るだけ"の意図を突破できちゃった UseCaseはredux-thunkを用いたThunkActionで実装 ○ CleanArchitectureを意識しないで作っていた頃に似た形で実装できた × Storeの構造に依存してしまった re-ducks構造が合わなかったので廃止した re-du

こんにちは、風邪はだいたい喉から来るぷーたんです。 「DDDの構成要素はこれだー」というのはたくさんあったのですが、 「このドメインオブジェクトはどの要素だー」と逆引きするものがなかったので調べてフローチャートにしてみました。 例えばドメインモデル図とコードがうまく合致しない時の見直しなどに使えるのではと考えています。 ではご覧ください♪ 検討フローチャート 図1.フローチャート 1) 複数のドメインオブジェクトを扱い、整合性を担保するか まず複数のドメインオブジェクトを扱うかを考えます。 ドメインモデル図では集約線が引かれていたり、複数の関係線が引かれていたりします。 図2.ドメインモデル図の例 上記のような場合であれば、「本棚」と「購入」はYes、「書籍」「在庫」「所持金」はNoです。 また、扱う複数のドメインオブジェクトに対して整合性を担保するかも考えます。 不要な場合、ドメインオブ

続編を書きました！ 続・ぼくのかんがえたさいきょうのReact+Redux+CleanArchitecture 前書き 最近話題のFluxにおいてモデルをどう扱うのかについて、自分もたまたま似た課題に取り組んでいたのでアウトプットしてみたものです。 まだ検証段階なのであれこれコメントいただけると幸いです。 タイトルは、、一度書いてみたかっただけです（照 発端 扱っているプロダクト（UI）のメンテナビリティ、エンハンサビリティが低い 業務ロジックとUI制御ロジックの分離がうまくできておらず、 ちょっとしたUI改善でも業務ロジックの考慮が必要な状況。 SPAになりさらにUIのコードは複雑化してきている UIだから複雑なアーキテクチャは要らないなんて言わず、DDDを取り入れてみたらどうか と言うことで、インフラストラクチャ層の分離がしっかりしている CleanArchitecture の採用を検

例 アカウントに対して更新権限を持つユーザーは、アカウント配下にキャンペーン、その配下に広告グループ、その配下に広告とキーワードをそれぞれ登録できなければなりません。 ↓ アカウントに対して更新権限を持つユーザーは、アカウント配下にキャンペーン、その配下に広告グループ、その配下に広告とキーワードをそれぞれ登録できなければなりません。 ヒト 更新権限を持つユーザー モノ アカウント、キャンペーン、広告グループ、広告、キーワード コト （キャンペーン|広告グループ|広告|キーワード）を登録する 業務用語の関係図を描く クラス図のように集約と汎化で関係付けていく 集約（A has-a B） 汎化（A is-a B） 例 ※ただしこの図は正しくありません  注意点 正しさを求めすぎない キリがないため。最初は2時間以上かけない。 細かく書きすぎない 大事なのは全体を網羅すること、一部に集中しすぎ

むちゃくちゃ間が空いちゃいましたが、明日会社でLTやるので書きますw 今回は**「no-restricted-syntax」=「制限構文を使っちゃだめ」** というルールの紹介と対応方法をまとめたいと思います。 具体的にはどんなもの？ no-restricted-syntax このルール自体に制約はなく、オプションで指定した構文を禁止する、といったもののようです。 ちなみに eslint-config-airbnb v14.1.0ではこんな感じで設定されています。 // disallow certain syntax forms // http://eslint.org/docs/rules/no-restricted-syntax 'no-restricted-syntax': [ 'error', { selector: 'ForInStatement', message: 'for.

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?