2019/06/20に見た記事等を雑に分類するだけ
- Go
-
Goのアーキテクチャを実例に学ぶ - 「開発スピード優先」でGMOペパボが採用したのはMVC - エンジニアHub｜若手Webエンジニアのキャリアを考える！
- ユーザーが使っているサーバがリクエストを受けた際、構成情報を取得するAPIを作成するプロジェクトでMVCを採用
- /modelディレクトリにモデル層を、/controllerディレクトリにコントローラー層をそれぞれ配置していくMVCの基本的な形
- マネージドクラウド系のサーバAPIでは、ほぼ共通した構成になっていて、ディレクトリ構成はMVCを採用しているプロジェクトがほとんど
- 以下を重視したシンプルな構成であることを重視
- 循環参照に陥らないようにすること
- 新しくプロジェクトに入ってきた人がすぐに構成を理解できること
- テストがしやすいこと
- 参考にしているディレクトリ構成例
- GoのORマッパーとしてのデファクトであるGORM(Active Recordに近い機能を持ったライブラリ)を採用したが、やりたいことに対してGORMの機能が大きすぎた
- MVCですらGoにとっては冗長
- 構成はシンプルにしておき、コード量が増えたときに適切にパッケージを分けるだけでも十分
- PlantUML
-
UMLの爆速プレビュー環境をVisual Studio Code + PlantUML Server on Dockerで簡単に構築する ｜ DevelopersIO
- シンプルな記法でUMLダイアグラムが作成できる
- 実際に業務で使う場合はテキストを書く→画像に書き出すという順序になる
- プレビューを確認しながら書くと効率良く作成できる → WEBアプリもある
- Docker Imageが公開されている
- Visual Studio Codeで編集環境を作る
- GitHub上でプレビューする
- 敵対的生成ネットワーク(GANs)
- マイクロサービス
- 現実の世界ではネットワークの障害や、依存先のサービスの障害が必ず発生する
- 複数のサービスを跨いで決済トランザクションのデータの整合性を担保することが課題
- 既知の手法
- MySQLでは2PCによるXAトランザクション機能(グローバルトランザクションとしてACID特性を担保させる手法)を提供している
- 2PCの場合、実行中すべての参加者がブロックされるなどの問題があり、性能と可用性上の懸念がある
- それに対し、Eric Brewer氏が「CAP定理」と一緒に「BASE」という可用性や性能を重視した分散システムの特性を2000年頃に提案した
- BASEの特性は、基本的には常に利用可能で、一時的に一貫性のない状態を許容して、即時ではなく結果整合性を取る(CAPの中でAPを重視)
- 中国で人気のモバイル決済サービスアリペイのBASE応用事例
- PaymentServiceで実践してきた手法
- フリーランス
- CSS
