サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
scrapbox.io/kawasima
#アーキテクチャ大全 設計のポイント 付与率の計算 顧客ランク (ロイヤルティ) 還元率アップキャンペーン 期間限定 店舗限定 ポイント付与のタイミング 即時 後日 キャンセル可能なアクションを伴うポイント付与は、キャンセルできなくなるタイミングまで実際の付与を遅らせる。 ただし、付与予定としてユーザに見せるケースがある。 ユーザがキャンセルした場合は、付与予定を取り消す。 有効期限 固定(dポイント型) 使うたびに延びる(ヨドバシ型) 期間限定ポイント キャンペーンとして有効期限の短いポイントを対象ユーザに一斉に付与する。 ↑の有効期限が使うたびに延びるタイプでも、期間限定ポイントは固定の有効期限を持つ。 参考資料 https://it-koala.com/point_system-814#i-4 https://engineering.reiwatravel.co.jp/blog/ne
数学の用語では全域性と呼ばれる code:f f = x => y 関数fの定義域xの取りうる値すべてに対応する値域yが存在することである。 全域性を持たない関数の例として代表的には割り算がよく取り上げられる。 code:divide.ts type Divide = (a:number, b: number) => number const divide: Divide = (a,b) => b !== 0 ? a/b : NaN 割る数に0は取りえないので、このdivide関数は全域性が無いことを意味する。 全域性を持たせるためには、3つのアプローチがあるとされる。 1. 定義域にデフォルト値を返す。 2. 戻り値にエラーケースを含める。 3. 引数(定義域)を全域性担保できる範囲に限定する。 1はこれが出来る場合と出来ない場合がある。上記例のように割り算の場合、どんな数字をデフォルト
ソフトウェア開発におけるContinuous 〇〇を収集する。総じて作業負荷、心的負担が大きくなるバッチ処理的に溜めて一度にやっていたプロセスを、日々のライフサイクルの中に組み込むことが目的である。 Continuous Integration すべての開発者の作業コピーを定期的に共有されたメインラインにマージする。 Wikipedia eXtreme Programmingでの説明 Martin Fowlerによる解説 Continuous Deployment ソフトウェアを頻繁に、自動的にデプロイメントする。 Wikipedia Continuous Delivery 継続的デリバリーとは、新機能、設定変更、バグ修正、実験など、あらゆる種類の変更を、安全かつ迅速に、持続可能な方法で本番環境に導入し、ユーザーの手に届けることができるようにしておく。 Wikipedia Martin F
起こりうる事故 ロックにより他のオンライン中のサービスに影響を与える。 トランザクション設定ミスにより途中の状態でコミットされる スロークエリ発行により、全体をスローダウンさせる。 統計情報が取得できておらず、SQL実行時間が長くなったりデータベースのリソースを喰ってしまったりする。 接続先を誤認して、本番環境でDELETE やTRUNCATE、DROP TABLEなどを発行してしまう ターミナルの操作ミスによって、クリップボードから誤ったSQLなどを発行してしまう。 パターン リハーサル コンテキスト 本番一発勝負では、不測の事態に陥ることもあるため、事前にリハーサルを行なって安全性を確認しておきたい。 フォース 本番相当の環境を用意できる。 マスクして持ってくることが定められたセキュリティポリシーに反していない。 ソリューション 本番相当のデータをテスト環境やステージング環境に構築し、
日本語だとどちらも「複雑」を意味するが、英語だと「Complex」と「Complicated」の2つの単語が該当する。 両者は明確な違いが無いともされるが、使い分けられるケースもある。Complicatedの方が頑張れば解消可能とされ、「複雑」じゃなく「込み入った」という訳語があてられることもある Cynefin Frameworkにおける使い分け Complicated: 分からないことは分かっている。理解するのは難しいが、時間と労力をかければ最終的にはわかる Complex: 分からないことが分からない。 英語ぷらすでの説明 Complicated: 関係性や状況が複雑。物理的でなく心情的・観念的にややこしい Complex: 構造や手順が複雑。物理的な複雑さ 対義語から Complexの対義語としてSimpleが使われるが、Complicatedの対義語としてはあまり使われない。 C
NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。
マーチン・ファウラー命名のドメインモデル貧血症は、ドメイン層っぽいデータをもつクラスを作りながらも、フィールドのGetter/Setterだけをつものを指す。そうしちゃうとドメインオブジェクトに業務知識が実装されず、それを使う側に任されることになる。
会員のドメインモデルを考える。属性としてemailAddressを持っていて、これは通知メールを送るのに使われる。
コンテンツサイトの「記事」を、あらかじめ掲載開始予定日を設定しておき、その日がきたら記事が公開される、また掲載終了予定日を設定しておいて、その日がきたら記事が非公開になる、というモデルを考える。
Domain Modeling Made Functionalで紹介されているドメインのドキュメンテーションのためのミニ言語です。
ドメインモデルには、完全性と純粋性、そしてアプリケーション性能の3つ全てを同時に満足させることは難しい場合があるという話。
JavaScript syntax defines several native data types that are not included in the JSON standard: Map, Set, Date, Error, Regular Expression, Function, Promise, and undefined.
このツールは、全体的な傾向を把握するためのもので、意図的に不正確な指標になっている。そのため個人の仕事のパフォーマンスを評価するために使ってはいけない。
ここでは画像やPDFなどの文書ファイルをアップロードし、別のWebページで画像を表示するのに使ったり、別のユーザにアップロードした文書ファイルを見せたりダウンロードさせたりする用途を考える。
Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す
型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。
https://github.com/ddd-crew/ddd-starter-modelling-process/raw/master/resources/ddd-starter-modelling-process.jpg
サイトの検索導線からも全部見えるようになったようです。 マスタリング・イーサリアム ―スマートコントラクトとDAppの構築 https://www.oreilly.com/library/view/-/9784873118963/ 初めてのGraphQL ―Webサービスを作って学ぶ新世代API https://www.oreilly.com/library/view/-/978487311893
データベースの検索メソッド(リポジトリとかDAOとか呼ばれる責務のもの)をどう設計するかは、選択肢が多く考えられる。それぞれの例と判断基準について検討してみよう。 例えば、このカルーセル(carousel)みたいなものを考える。現在のRoomClipのカルーセルは、その日に投稿されたフォトを10件程度選択する仕様である。
世の中のロギングライブラリの主な想定用途はこれである。必要な箇所やレベルに応じて出力制御をするために、ログカテゴリやログレベルが存在する。
「テストコードがなくて品質が良くないんですよ…」というシステムのソースコードを覗くと、いろんなロジックがコントローラの中に書かれたファットコントローラだったり、ビジネスロジック層と定義はされているけれども中身はただのDAOだったりということが多くあります。 そういうファットコントローラだと書けるテストは、以下のように入力値のバリデーションエラー1つテストするだけでも、コントローラの依存関係を解決し呼び出す必要があり、テストコード書くにもモックライブラリの知識が要求されるようになるし、書いたテストも実行速度が遅くなりがちです。さらにアサーション対象はコントローラの戻り値、すなわちテンプレートに渡す変数であったり、JSON化するためのオブジェクトで、この例のようにバリデーションエラーの場合は、ユーザに表示するためのメッセージ文しかないこともあり、アサーション書くのも一苦労だし、メッセージを修正
レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。
microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
例えば、サービスAがあるファイルに書き込み、サービスBがそのファイルを読み込むようになっていた。どちらもハードコードされていて、サービスAがパスを変更したらサービスBがエラーになった。それで初めて2つのサービスの関連性に気付いた。というようなケース。
このADRをレビューするにあたっては、コンテキストのセクションもよくよく議論すべきで、意思決定が妥当かだけ見ても、「実はコンテキストに誤りやあやふやなところがありA案よりもB案の方が良かった…」みたいなことが発生するし、十分にコンテキストが理解されていない第3者や有識者をまじえてのレビューでは、レビューアに意思決定の構造を理解してもらいにくい、ということもある。
職業プログラマは仕様書をよく読み、正しく実装する能力が必要とされる。 このためのトレーニング題材として、(よく)使われている/使えそうなものをリスティングする。 AWSサービスのスタブ実装 https://docs.aws.amazon.com/index.html AWS SDKがあるので、テストがしやすい。 ついでに学べる技術 XMLシリアライズ HTTPサーバの実装 HTTPサーバの実装 h
社員は退職しても別のイベントデータと関連付けされているので、消せないことが多いでしょう。ただ氏名等個人情報に関わるものは持たないようにしなくてはならないので、サブタイプで区別します。
Architecture Decision Records(ADRs)は、アーキテクチャ上の意思決定をドキュメントとして残す方法の1つです。Release It!の著者であるMichael Nygardのブログによって広まり、ThoughtWorks社のTechnology Raderでも「adopt」になっています。
次のページ
このページを最初にブックマークしてみませんか?
『kawasima』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く