ソフトウェア工学

私はマイクロサービスに不慣れです。私の理解から、DDDはビジネスドメインを中心にマイクロサービスを構築するように言っています。つまり、会議予約システムのコンテキストでは、優れたマイクロサービスはAppointmentSchedulerやSendNotificationのようなものです。 この例では、これらの両方のマイクロサービスがビジネス機能を果たすためにユーザーデータにアクセスする必要があり、それを提供するための最良の方法に苦労しています。 私には、ユーザーはマイクロサービス内のエンティティとして存在する必要があるオブジェクトのように見えますが、ほとんどすべてのマイクロサービスに存在する必要があります。これにより、多くの重複が発生します。 もう1つのオプションは、ユーザーデータベースでCRUD操作を提供するユーザーマイクロサービスを用意することです。これは、他のマイクロサービスがユーザーデータにアクセスするために使用できますが、私が抱えている問題は、分散モノリスになるまでサービスを密結合することです。これは、モノリス自体よりもわずかに優れています。 私の推論は有効に見えますか？他の人はどのように問題に対処していますか？

9 microservices 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 昨年休業。 ステートフルアプリと非ステートフルアプリについて学習してきましたが、このトピックについてはまだ少し混乱しています。 たとえば、ユーザーがsocket.io経由で接続するとすぐにランダムルームに割り当てられるNodeで実行しているアプリがあるとします。これらは4の部屋であり、永続的なものではありませんが、ハッシュマップとしてグローバル変数に格納されます。私はdb（クエリが多すぎる）やredis（高すぎる）を使用していません。 これはステートフルアプリの例ですか？

9 terminology  node.js  state 

HATEOASは「アプリケーション状態のエンジンとしてのハイパーメディア」の頭字語です。「アプリケーション状態のエンジン」とは何ですか。特に、「ハイパーメディア」のエンジンはどうですか。 私が理解できる限り、HATEOASとHALなどの関連する標準はRESTの「発見可能性」の部分に対応しています。 春の議論それについては、のように要約したものです。 HATEOASを使用すると、出力により、仕様やその他の外部ドキュメントを検索せずに、サービスと対話する方法を簡単に収集できます。 たとえば、HAL準拠のJSONなどを使用してHATEOAS準拠の応答を行う場合、クライアントはルートAPI URL以外のリソースパスをハードコーディングする必要がないということです。 「アプリケーションの状態」とは関係がないように見えることを除いて、これは完全に理にかなっています。せいぜい、サーバー構成（つまり、リソース（サーバー構成）のURLを変更した場合）を使用することで、コンシューマはどこにあるかを見つけることができます。 HATEOASが何であるかを私が収集できたことについて少し詳しく説明すると、同じ説明ページからの抜粋があります。HATEOASがリソースの場所を発見する問題を解決したことが示されています。ただし、「アプリケーションの状態」とは関係がないようです。 単純なJSONプレゼンテーションは、伝統的に次のようにレンダリングされます。 { "name" : "Alice" } 顧客データはありますが、データには関連するリンクは含まれていません。 HATEOASベースの応答は次のようになります。 { "name": "Alice", "links": [ { "rel": "self", "href": "http://localhost:8080/customer/1" } ] } この応答には、その人の名前だけでなく、その人がいる自己リンクURLも含まれています。

9 rest  hateoas 

私のプログラムは、最初から最後まで一連のステップを実行する必要があります。ただし、異なる入力に基づいて開始点は異なります。たとえば、最初のステップから最後まで実行されるもの、2番目のステップから最後まで実行されるもの、3番目から最後まで実行されるものなどがあります。 シンプルなデザインが必要ですが、現在は次のようなフォールスルースイッチを使用しています。 switch (step) { case 1: //do the 1st step //fall through, so no break here case 2: //do the 2nd step //fall through case 3: //do the 3rd step //fall through ... } それは機能しますが、フォールスルーコードは常に私を不快にします。それを行うためのより良い簡単な方法はありますか？

9 design  design-patterns  coding-style  clean-code  switch-statement 

C＃では、DateTimeプロパティMonthのタイプはint（32ビットの符号付き整数）ですが、その範囲は1〜12のみです。C＃チームが（8ビットの符号なし整数）intなどの小さい数値型を選択した理由は何byteですか？

9 c#  memory 

私はすっきりしたコードが大好きで、コードを可能な限り最善の方法でコーディングしたいと思っています。しかし、常に1つありましたが、本当に理解できませんでした。 メソッドに関する「懸念の分離」が多すぎるのはいつですか？ 次のメソッドがあるとします。 def get_last_appearance_of_keyword(file, keyword): with open(file, 'r') as file: line_number = 0 for line in file: if keyword in line: line_number = line return line_number この方法はそのままでも問題ないと思います。それはシンプルで読みやすく、そしてその名前が言うように、それは明らかにそうです。しかし、それは「ただ1つのこと」を実際に行っているのではありません。実際にファイルを開き、それを見つけます。それは私がそれをさらに分割できることを意味します（「単一の責任の原則」も考慮する）： バリエーションB（まあ、これは何となく理にかなっています。このようにして、テキスト内のキーワードの最後の出現を見つけるアルゴリズムを簡単に再利用できますが、「多すぎる」ように見えます。理由は説明できませんが、「感じる」 「それはそのように）： def get_last_appearance_of_keyword(file, keyword): with open(file, 'r') as text_from_file: line_number = find_last_appearance_of_keyword(text_from_file, keyword) return line_number def find_last_appearance_of_keyword(text, keyword): line_number = 0 …

9 single-responsibility  encapsulation  separation-of-concerns 

何かの列挙/コレクションであるクラスを実装する必要があることがよくあります。このスレッドのために考えてみましょう不自然な例のIniFileContentラインの列挙/コレクションです。 このクラスがコードベースに存在しなければならない理由は、ビジネスロジックがいたるところに広がらないようにする（=をカプセル化するwhere）ためであり、可能な限りオブジェクト指向の方法でそれを実行したいからです。 通常、以下のように実装します。 public sealed class IniFileContent : IEnumerable<string> { private readonly string _filepath; public IniFileContent(string filepath) => _filepath = filepath; public IEnumerator<string> GetEnumerator() { return File.ReadLines(_filepath) .Where(l => !l.StartsWith(";")) .GetEnumerator(); } public IEnumerator IEnumerable.GetEnumerator() => GetEnumerator(); } IEnumerable<string>使用が便利になるので、実装を選択します。 foreach(var line in new IniFileContent(...)) { //... } しかし、そうすることでクラスの意図を「隠す」のだろうか？人がIniFileContentインターフェースを見たときだけ見るEnumerator<string> GetEnumerator()。クラスが実際に提供しているサービスは自明ではないと思います。 次に、この2番目の実装を検討します。 …

9 c# 

マイクロサービスアーキテクチャに基づいてアプリケーションを設計しています。 このアプリケーションでは、Authマイクロサービスが必要です。 また、おそらく複数のアドレス、アバター画像などの追加のユーザー情報を保存する必要があります これにより、2つのマイクロサービス（1つは認証用、もう1つはユーザー用）を持つというアイデアにつながります。 これまでのところ、私は次のアイデアを持っています： 認証サービスが、追加のアドレス（おそらくアバターなど）を含むユーザー情報を保持するリソースサーバーになることも許可します。これは、ユーザーに関連するすべてを1か所にまとめて、新規登録などの操作の複雑さを軽減できるので、便利なソリューションです。ユーザー、ユーザーの削除。ただし、このソリューションはマイクロサービスの概念と矛盾しているようですが、私にとっては、このソリューションが最も魅力的です 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理のみを担当し、ユーザーに関連するデータは保存しません。トークンのリクエストが受信されると、Authサービスはユーザーを呼び出してユーザーデータを受信し、決定を行います 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理を担当し、認証に関連するユーザー情報の一部（おそらくパスワード、ロール）も格納します。ユーザーサービスは、追加のアドレス、アバターなど、他のすべての情報を保持します。この方法は、複雑なユーザーの削除/新しいユーザーの作成操作を必要とするため、複雑すぎるようです さて、これらの解決策の1つを選択する必要がありますが、迷っていて、どれが正しい解決策なのかわかりません。 これに関するアドバイスをいただければ幸いです。 ありがとう

9 design  architecture  microservices  authentication 

私のチームはGit Stable Mainlineブランチモデルを使用しており、最初のリリースブランチを作成しようとしています。これまで読んだことから、リリースブランチはマスターブランチからサイロ化されており、完全にマスターにマージされることはないようです。代わりに、リリースブランチで修正が行われた場合、通常はマスターブランチにチェリーピックされます。現在のリリースを次のリリースの開発から完全に分離したまま、現在のリリースの準備と同時にマスターで次の機能セットを開発できるようにしたいので、これは私にとって意味があります。 これらのリリースブランチはどのくらいの期間保持する必要がありますか？それらを完全にマスターに戻す必要がある場合はありますか？

9 git  release-management 

WPF開発者として、ユーザーインタラクションとアプリケーションのフロントエンドを明確に扱っていても、プラットフォームがWebではないためフロントエンドとは見なされないことに気づき、混乱しました。 デスクトップアプリケーションでは、Webのようにフロントエンドとバックエンド（それぞれUIとドメイン）が分離されていないと思っていました。ただし、多くのアプリケーションには、特に企業内でこの違いがあります。私が専門的に開発したデスクトップアプリケーションのほとんどは、Web APIによって提供および受信されるデータ用のデスクトップクライアントにすぎませんでした。この意味で、クライアントは非常にフロントエンドです。 では、この答え、「フロントエンドは」という作家の状態なければなりません「クライアント側」のに対し、ブラウザで実行は、デスクトップアプリケーションを潜在的に含めることができます。 では、なぜ「フロントエンド」はWeb開発のみに関係するのでしょうか。

9 web-development  front-end  professional-development  desktop-development 

ここで説明するように、私はクリーンなアーキテクチャを使用してプロジェクトを構築しようとしています。Goでこれを行う方法についての素晴らしい記事を見つけました。 この例は非常に単純なものであり、作成者はコードをパッケージ内のレイヤーに基づいて名前が付けられたパッケージに入れます。ボブおじさんのアプリケーションのアーキテクチャはその意図を明確に伝えるべきだという考えが好きです。したがって、ドメイン領域に基づいたトップレベルのパッケージをアプリケーションに持たせたいのです。したがって、私のファイル構造は次のようになります。 /Customers /domain.go /interactor.go /interface.go /repository.go /... the same for other domain areas これの問題は、複数のレイヤーが同じパッケージを共有することです。したがって、依存関係のルールがいつ違反されているかは明確ではありません。何が何に依存しているかを示すインポートがないためです。 私は、これはあなたが個々のファイルをインポートすることができますので、問題の限りではありませんので、Pythonの背景から来ているcustomers.interactorインポートすることができcustomers.domain。 パッケージをネストすることにより、gOで同様のことを実現できます。その結果、customersパッケージにはドメインパッケージとインタラクターパッケージなどが含まれます。これは不格好に感じられ、同じ名前のパッケージは扱いが面倒です。 別のオプションは、ドメイン領域ごとに複数のパッケージを作成することです。1つはcustomer_domainと呼ばれ、もう1つはcustomer_interactorと呼ばれます。しかし、これも汚い感じがします。これはGoのパッケージ命名ガイドラインにうまく適合せず、名前には共通のプレフィックスが付いているため、これらの個別のパッケージはすべて何らかの方法でグループ化する必要があるように見えます。 では、これに適したファイルレイアウトは何でしょうか。

9 architecture  golang 

いくつかの統計情報を返すAPIエンドポイントがあります。現在、応答は次のようになります。 オプション1： { "stats": [ { "name": "some-stats-key1", "value": 10 }, { "name": "some-stats-key2", "value": 20 } ], ... other keys } しかし、これは少し複雑に見え、私はそれをどのようにするのか： オプション2： { "stats": { "some-stats-key1": 10, "some-stats-key2": 20 } ... other keys } オプション1は拡張が簡単ですが、ユーザーにとって快適ではないことを理解しています。これらのオプションのいずれかを使用して直面する可能性がある他の問題は何ですか？または、次のようなハイブリッドソリューションを作成する必要があります。 オプション3： { "stats": { "some-stats-key1": { "name": "some-stats-key1", "value": 10 }, "some-stats-key2": { …

9 rest  api  json 

このシリーズを進めています。作者は、オブジェクト指向プログラミングでは状態が維持されるため、単体テストを書くのは難しいと述べています。彼はまた、関数型プログラミングは（常にではない）状態を維持しないので、単体テストを書く方が簡単だとも言っています。この問題を示す例は見当たりませんでした。これに該当する場合、オブジェクト指向プログラミングと関数型プログラミングの単体テストを比較する例を教えていただけますか？

9 object-oriented  unit-testing  functional-programming 

void Animation::playAnimation() const { static const int index = 0; const std::string& animationFileName = m_animationContainer.getAnimationName(index); static const int zOrder = -1; static bool isLooping = false; AnimationBank::play(animationFileName, zOrder, isLooping); } 定数ローカル変数を次のように定義するメリットはありますstaticか？またはそれは不必要であり、悪い習慣ですらあります。

9 c++  c++11  c++14 

私はそれを使用するプログラムのログで役立つ可能性のある多くの情報を含むライブラリを書いていますが、私のライブラリを使用するプログラムができるような方法でそれを公開する最良の方法がわかりませんライブラリのログを独自のログとシームレスに統合します（必要な場合）。 ライブラリに特定のロギングライブラリを選択すると、ライブラリを使用するための依存関係のリストに追加され、メインプログラムがそのライブラリに関連付けられます。メインプログラムで使用される複数のライブラリがこれを行った場合、それぞれが異なるライブラリを選択した可能性があります。 私は、プログラムでC ++ストリームオブジェクトをライブラリに登録して使用できるようにすることについて考えました。それは比較的一般的な目的のようですが、データがログに記録されるときにコンテンツとメタデータで呼び出されるコールバック関数をメインプログラムに登録することも考えました。別のオプションは、データを処理する必要があるときはいつでもメインプログラムが取得できるように、ログデータをライブラリ内のある種のリストに格納し、メインプログラムがデータを処理する時間を決定できるようにすることです。 自分の状況に最適なものを決定できるように、さまざまなアプローチの提案と長所/短所を探しています。

9 c++  logging