状態設計から「なんとなく」を無くそう
ウォンテッドリー株式会社の社内イベント "Tech Lunch" で話した発表です。 プログラムには大小さまざまな粒度の「状態」が存在します。 状態の設計を工夫することで、コーナーケースの発生を抑止し、ユーザー体験を最適化することができます。 本発表では、私が普段どのように「状態」について考えているか、言語や環境を問わずできるだけ普遍的に使える形での言語化を試みます。本発表を通じて、「状態」をなんとなくではなく合理的に設計するためのヒントを提供します。 GoogleスライドのURL: https://docs.google.com/presentation/d/1PNzz69UV05HlKPuWGlooemnPslLbLKsyLwl3R4U_XqE/edit
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み｜ハイクラス転職・求人情報サイト AMBI（アンビ）
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み 大規模なソフトウェア開発においてモノリシックかマイクロサービスかというアーキテクチャの議論がありますが、近年は第3の選択肢としてモジュラモノリスが話題になっています。いったんマイクロサービス化に舵を切りながら現在はモジュラモノリスに取り組むアソビューの考え方や進め方について、VPoEの兼平大資（disc99）さんによる寄稿です。 アソビューでは、現在の事業状況にマッチしていることや過去の経緯から、モジュラモノリスを中心としたアーキテクチャを採用しています。 今回は、なぜその選択をし、どのように実現しているかを紹介します。 記事の前半では、アソビューが提供する事業や、アーキテクチャに対する考え方、開発組織の歩みなどを説明します。 中盤以降は、アソビューにおけるモジュラモノリスへの取
認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏
自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える
事業を支える技術選定 / Engineering Decision Making Process For Business - Speaker Deck
Transcript 事業を支える技術選定 コネヒトマルシェオンライン「事業を支えるWeb開発」@itosho 1 自己紹介 ▪伊藤 翔 @itosho ・コネヒト株式会社 執行役員CTO ・Backend Engineer / PHP, Go ・stand.fm はじめました ・https://stand.fm/channels/5ec2e733f654bbcab4c123a2 Follow me! 今日のテーマ「技術選定」 4 何故、技術選定は難しいのか？ ▪正解がない ・判断軸が多岐に渡り、会社の状況によっても変わる ・イデオロギーが対立しやすいトピックであり、合意形成が難しい 難しいからこそ向き合う価値がある ▪今日話すこと ・技術選定をするにあたり、どうやって意思決定をしているか ・正解がないトピックなので一つの考えとして聞いてください ※話のトピック的に、何かを「選ぶ」ので必然
詳細設計書に何を書くべきか？ - Sacrificed & Exploited
詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと１対１に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容（内部の処理の実装方法）の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://wiki.c2.com/?StableDependenciesPrinciple
