鬼滅の概念モデリング - Qiita
はじめに 概念モデリングとは、システムのドメインを構成する概念を発見しその属性・振る舞い・関連を定義する活動である。例えば、段階的に理解する O/R マッピングで実例として挙げたシンプルな課題管理システムにはプロジェクト・課題・コメントの 3 概念が登場するが、これらを概念モデルとして表すと以下のようになる。 本来、概念モデリングは DDD の主要な活動の一つである。DDD の Whirlpool プロセスの図を見てみよう。Model は Code Probe と Scenario に挟まれた中心概念であり、常時フィードバックを受けて更新されることが想定されている。 にもかかわらず、日本での DDD 関連の議論においては、概念モデリングが語られることは少なく、レイヤ分割やクラス類型といったアーキテクチャ的側面への偏りが見られる。パターンカタログを眺めればわかる通り、それらの要素は DDD
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
管理画面の作り方とは？設計のときに気をつけたい9つのこと
1. 認証をどうするか決めるまず認証をどうするか決めます。GoogleやSlackなどのアカウント連携がよさそうです。どのアカウントを使うかは、組織が利用しているプラットフォームに応じて決めればいいです。あとは、IPアドレスによる制限をかけるなど、他の手段とあわせて認証するとセキュリティが強化されます。 実装がラクだからといって、プロダクト本体のユーザー基盤を利用してしまうと、セキュリティの担保が難しくなったり、管理画面がプロダクト本体と密結合になってしまうので、基本的には避けた方がいいと思っています。 2. 認可する対象を決める次に認証した運用者の役割によって許可する操作を分けていきます。たとえばアルバイトや業務委託の方など、アクセスしていいデータが変わってくることがあるので、これを分けます。 やり方としては、まず管理画面上の操作の一覧をスプレッドシートなどに書き出し、許可する役割をセッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
