強いて言えば「集約どう実装するのかな、を考える」な話
3. CartにCartItemを追加する Add Cart Add Cart Add Cart 1 1 1 { “productId”: “mikan”, “quantity”: 1 } API Endpoint AddCartItemUseCase { “userId”: “kawasima”, “productId”: “mikan”, “quantity”: 1 } 4. ユースケースシナリオ 1. ユーザのカートが存在することを確認する。 2. productIdが実在する商品かつ販売中の商品であることを確認する。 2a. 販売中でない場合 2a1. その旨をユーザに通知して終了 3. カートに商品と数量を追加する 3a. 既にカートの中に同一の商品があれば数量を足し合わせる 3a カート内の商品の数量が100を超える場合 その旨をユーザに通知して終了 4. カートの内容を保存す
レイヤードアーキテクチャ - kawasima
POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた
結合度 - kawasima
https://www.infoq.com/jp/news/2020/04/balancing-coupling-ddd-europe/ https://speakerdeck.com/vladikk/balancing-coupling-in-distributed-systems モジュールやコンポーネント間の結合の度合いは、 強度(Strength) 距離(Distance) 変動性(Volatility) の3つの切り口による評価がある。これらは直交した評価軸ではない。 強度 https://www.linkedin.com/pulse/types-coupling-ahmed-adel/ 昔から出てくる分類 内容結合(Content Coupling): 別のモジュールの内部実装を参照する 共通結合(Common Coupling): グローバル変数を共有する 外部結合(Exte
Microservices分割大全 - kawasima
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のサブドメ
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
アーキテクチャ大全 - kawasima
お気に入り / ページネーション / 検討リスト / カテゴリ毎の件数表示 / Conversation threading / オートログイン / 途中保存 / 予約 / 未読管理 / アンケート
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
2. What is Software Architecture ● IEEE1471「コンポーネント、それらの関係や環境、設計やそのコンポーネント、それらの関係や環境、設計やそのそれらの関係や環境、設計やその関係や環境、設計やそのや環境、設計やその環境、それらの関係や環境、設計やその設計やそのや環境、設計やそのその関係や環境、設計やその 進化を左右する原則に具現化されたシステムの基本的な構成」を左右する原則に具現化されたシステムの基本的な構成」左右する原則に具現化されたシステムの基本的な構成」する原則に具現化されたシステムの基本的な構成」原則に具現化されたシステムの基本的な構成」に具現化されたシステムの基本的な構成」具現化を左右する原則に具現化されたシステムの基本的な構成」されたシステムの基本的な構成」システムの基本的な構成」の関係や環境、設計やその基本的な構成」な構成」構成」」 ● M
チーム力向上のためのエトセトラ - Qiita
この半年間、久しぶりに開発チームのマネージャ的な立場もやることになったので、「ふつうの受託開発チームのつくりかた」以来、工夫したことをまとめておきます。「ふつうの受託開発チームのつくりかた」未見のかたはぜひそちらも見てみてください! チームに名前を付ける 私の受け持つチームは伝統的に「ラスカル」の名を付けるようにし、チームのアイデンティティを保つようにしています。チームメンバも本当は出来るだけ長く担当してもらいたいのですが、大きなSIerだとそれが難しいこともあります。 通常のプロジェクトチームだと、サブシステム名くらいで呼ばれることでしょう。これは、そのプロジェクトが終わったらチームも終わり、で帰る場所も無くなることを意味しますし、愛着をもって働くことは難しくなります。 メンバが多少入れ替わっても、チームは継続する"モーニング娘。方式"であれば、またいつか戻ってくることもできるし、OBと
[システム間連携]接続方向を逆転させるとうまくいく - Qiita
システムAの更新内容を、別のサーバにあるシステムBにも反映させるためにデータ送る、というケースを考えます。 主流はWeb APIかMOMを使う方法かと思います。(俯瞰的な話は、20日目のこざけさんが書いてくれる、はず) しかし、A,B間で同時に一貫性を保たなくても良いケースは、企業間システム連携ではよくあります。 CAP定理でいうところの可用性＋分断耐性をとりにいくパターンです。が、最大数秒程度で結果整合性は保ちにいきます。 システム間の接続 非同期ながら、ほぼリアルタイムでデータを反映していくので、応答性の高い接続手段が求められます。だが中間経路をHTTPでないプロトコルを通すハードルが高かったり、ファイヤーウォールなどで長時間接続を切られたりする問題があるので、私はよくWebSocketを使います。 だいたいの構成は以下のようになります。同期エージェント間をWebSocketでつなぎ、
![[システム間連携]接続方向を逆転させるとうまくいく - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9e6b26bad6ab3b6b40219c713c4e519da8866144/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgyJUI3JUUzJTgyJUI5JUUzJTgzJTg2JUUzJTgzJUEwJUU5JTk2JTkzJUU5JTgwJUEzJUU2JTkwJUJBJTVEJUU2JThFJUE1JUU3JUI2JTlBJUU2JTk2JUI5JUU1JTkwJTkxJUUzJTgyJTkyJUU5JTgwJTg2JUU4JUJCJUEyJUUzJTgxJTk1JUUzJTgxJTlCJUUzJTgyJThCJUUzJTgxJUE4JUUzJTgxJTg2JUUzJTgxJUJFJUUzJTgxJThGJUUzJTgxJTg0JUUzJTgxJThGJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz02OWE5YmIzM2YxNTIyZTQ3YmNiYTczN2E1NmZlZTlhMQ%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBrYXdhc2ltYSZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ODAyNDk1Y2IwNTFhMTYzMTFhM2NkYWE5OWU2NmJlYzQ%26blend-x%3D120%26blend-y%3D500%26blend-mode%3Dnormal%26s%3D8943a150f1c778f23b4d782e0d1d1e40)
至高のファイルアップロード - Qiita
システムエンジニアにとって頻出機能のひとつで、要件がモリッとしがちなファイルアップロードについてです。アップロードファイルもただの画像やPDFではなく、ExcelやCSVファイルをアップロードして、中身を読み取ってデータベースに格納する、あれを対象とします。 標準的なファイルアップロードでの設計ポイント ファイルのアップロード機能を実装しようとなると、以下のような点の設計を考える必要があります。 同期? 非同期? タイムアウトのリスクがあれば、非同期にする ブラウザのタイムアウト 通信経路(プロキシやファイヤウォール)でのタイムアウト Webサーバのタイムアウト ユーザがレスポンス返ってこないので、処理を中止するリスク 非同期の場合の実行方式 Webサーバ内でスレッドを新規に作る or 別プロセスへ処理をディスパッチする 流量制御のためリクエストをキューイングする Progress 長時間
究極のファイルダウンロード - Qiita
アップロードと比較するとタイトルは釣り気味なのですが、ダウンロードにまつわるパターンをまとめます。 ふつうのダウンロード アップロードほど考えなきゃいけないことは多くないですが、ハマりポイントはいくつかあります。 ファイル名 何も対策せず日本語をファイル名にすると、当然のように化けます。
Shift_JIS文化からUTF-8への移行ガイド - Qiita
まだまだ場所によってはShift_JIS文化は根強く、2015年が終わろうとしている現在でも、「ようやく我が社もUnicodeでシステムを作ることを考えるっ！」なんてところは多くあるかと思います。 そんな現場で、これまでJavaでShift_JISでシステム構築してきたSIer向けのUTF-8移行ガイドです。 文字長のチェック 文字長の入力チェックはShift_JISの世界では、半角文字は1バイト、全角文字は2バイトなので、以下のようなチェックロジックになっていたかと思います。 if (inputValue.getBytes("Windows-31j").length > 20) { errors.add("hoge", new ActionMessage("errors.maxlength", "ほげ", 10)); } UTF-8ではそれらの文字は、1バイト～3バイトで表されるので、バ
セキュリティ監査で文句を言われないHTTPステータスコードの使い分け - Qiita
最近はハンドリングしくてもいいや的な、入力改ざんで発生するバリデーションエラーをそのまま500のHTTPステータスで返すと、攻撃者が「なんか攻撃成功しちゃいそう」って思っちゃうとかなんとかで、監査的なところから「500はやめろ」って言われることがあります。 一理ある ということで、安易に500を返さない方法を考えてみます。 HTTPステータスコードにあまり馴染みのない方は、こちら…ではなく、こちらをまず読んでください。 HTTPステータスコードの使い分け基礎 400 まず、ユーザの入力値、データの状態によってエラーになるケースは 400 Bad Request とします。エラーメッセージを表示して再入力を促すHTMLページを返す、一般的な入力エラー系の遷移は200 OKを返しても、実用上問題はないかと思います。 ユーザの操作が原因で、サーバ処理がエラーになった場合も400で扱うのはおかしい
キメるClojure
3. Clojureならではなこと… 文法 → Lisp方言 イミュータブルなデータ構造 → HaskellやScalaにもある 遅延評価 → その他多くの関数型言語と同じ CSP(core.async) → golangと同じ Future/Promise → JavaのFutureそのもの Almost nothing in Clojure is new (Clojure Appliedより) 6. Syntax Clojure Ruby String "Clojure" "Ruby" Keyword :clojure :ruby (Symbol) Numeric 123 (long) 123.0 (double) 22/7 (Ratio) 123 (Integer) 123.0 (Float) 22r/7 (Rational) List (1 2 3) - Vector [1 2 3
システムエンジニアのカレンダー | Advent Calendar 2015 - Qiita
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
多い日も安心設計 - Qiita
アプリケーションエンジニアの多くは、眠れない夜を過ごしたことがあるでしょう。特に月に一度の…「月末締めバッチ」の日は。 そんなデータ量の多い日や、初モノのバッチが動く日でも安心して眠れるためのバッチ設計を考えてみます。 ログの設計 まず何はなくともログです。きちんとしたメッセージを出せていれば、専任の人がリカバリ可能にもなるってものです。 Audit用のログなど業務要件の強いものを除いては、だいたい3種類に分けるようにしています。 プログレスログ リカバリログ 例外ログ(調査のため) この分類でファイル単位も分けます。ログを必要とする人が、それぞれ異なるからです。 プログレスログ プログレスログは、特に長時間かかるバッチに対して、現在どのくらいまで処理が出来ているのかを目的として出力します。 トラブル発生時や、大規模移行作業時には、バッチの定期的なモニタリングと報告の必要が出てきます。「あ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Atomic Architecture
それはYAGNIか? それとも思考停止か?
履歴を持つデータの設計
GitBook