Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Europeで行った基調講演で、このように解説した。正当なコンテキストには、洗練されたモデルと表現力のあるユビキタスな言語による、明確な定義がある。整然として見えるシステムの定義は、氏にとっては非常に疑わしいものだ。氏が関わった大規模なソフトウェアシステムは、いずれも整然としているとは言い難いものだったからだ。先日公開されたプレゼンテーションで、氏は、さまざまな種類のコンテキスト境界や、マイクロサービスとの関係について説明している。Design"の著者でもあるEvans氏は、概念としてのコンテキスト境界について、何年も前からコミュニティの関心は高まっているものの、まだまだやるべきことのある領域だ、と指摘する。Evans氏が開発チームで時々目にする混乱のひとつは、コンテキスト境界とサブドメインの区別に関するものだ。この2つは理想的な世界では一致するが、現実には不整合であることが少なくない。例として氏は、現金口座とクレジットカードを中心に構成された銀行を挙げている。銀行のドメイン内のこれら2つのサブドメインもまた、コンテキスト境界である。その後、ビジネス口座と個人口座を中心としたビジネスの再編成によって、これらとは別の2つのサブドメインが存在するようになったが、コンテキスト境界は同じままだ。従って、新たなサブドメインとは整合していないことになる。mud)"化するリスクが高くなる。成熟した生産的なコンテキストは価値を生み出すが、その多くは時代遅れのコアドメインの概念に基づいている。ここで問うべき重要な質問は、コアドメインの現在のビューと比較した時、コアドメインの不整合がどれ程のものか、これがビジネスの発展をどの程度制約しているか、ということだ。不整合が大きすぎると、既存のコンテキストを転換する要求が生じる可能性がある。Evans氏の経験では、そのような転換はうまくいかないことが多い。ソフトウェアの基本的な前提の変更は、多くの場合、システムをだめにする。従って氏は、そのような方法には否定的だ。Evans氏が取り上げた別のコンテキストのひとつは、Quaint(古風な)コンテキストと呼ぶべき古いコンテキストだ。機能的には今でも有用だが、旧式のテクノロジを使って実装されていたり、ドメインの現在のビジョンに沿っていない可能性がある。Shelf(OTS)コンテキストとGenericサブドメインコンテキストの組み合わせで、他のコンテキストが準拠すべき重要なサブドメインを、従来の方法で総称的サブドメインとして定義するものだ。氏は、GeneralistコンテキストとSpecialistトコンテキストについて説明し、その比較を行っている。Evans氏はマイクロサービスについて、最大のチャンスであると同時に、我々が長く抱えていた最大のリスクであると考えている。我々が最も関心を持つべきことは、我々の従事するビシネスのニーズを満たす上において、マイクロサービスが果たすことのできる能力である。氏は、その"バンドワゴン効果"についても警鐘を鳴らしている。氏が問題視する点のひとつは、マイクロサービスはすなわちコンテキスト境界である、と多くの人たちが信じていることだ。それは単純化し過ぎだ、と考える氏は、それに代わるものとして、マイクロサービスに関連する4種類のコンテキストを取り上げている。Internal"は、サービスの動作方法について述べたものだ。マイクロサービスがコンテキスト境界であるという時、人々が思い浮かべるのはこのタイプだ、とEvans氏は言う。ここでは、サービスは他のサービスから分離され、自律的なチームによって処理される。コンテキスト境界の定義には適合しているが、それでは不十分だ、と氏は指摘する。このタイプだけを使用すると、相互に通信する方法の分からないサービスが出来上がることになるからだ。Service"では、他のサービスとの通信を記述する。ここでの課題のひとつは、チームがそれぞれのAPIをどのように設計し、適応するか、にある。データフローの方向によって、コンシューマが常に上流のデータフローに準拠するように、開発の依存関係を決定することは可能だが、他にも方法があるとEvans氏は考える。高い影響力を持つグループがAPIを作成すれば、他のグループはそれに準拠しなければならない。オーソリティに対しては、データの方向に関係なく、そのAPIに準拠しなければならないのが一般的だ。services"である。複数のサービスが相互に連携して何かを達成するような設計の場合、それらはひとつになってコンテキスト境界を形成する。注目すべきなのは、個々のサービスの内部では、APIで使用するモデルとはまったく異なるモデルを使用することが可能である、ということだ。Context"である。サービス間の相互作用もモデル化する必要がある、とEvans氏は指摘する。このコンテキストのモデルには、サービスが他のサービスと対話するときに使用するメッセージと定義を記述する。注目すべきは、このコンテキストにはサービスが存在しないことである。ここで取り上げるのは、メッセージ、スキーマ、そしてプロトコルなのだ。Assetは、レガシシステムをマイクロサービス環境に参加させる場合に有効である。その方法のひとつは、マイクロサービスのように見えて、他のマイクロサービスと相互作用するが、内部的にはレガシシステムと処理を行うインターフェースを用意することだ。これにより、構築済の新しいマイクロサービスに手を加える必要も、レガシシステムを変更する必要も回避することが可能になる。レガシシステムは変更に対して脆弱で、障害を発生したり、大きな泥玉になる可能性も少なくないのだ。最後にEvans氏は、DDDが実際に何であるかの定義を試みている。問題なのは、DDDをどの程度厳密に定義する必要があるのか、という点だ。定義には共通のビジョンと言語がなければならないが、イノベーションと改善を可能にする柔軟性も必要だ。コミュニティは重要だが、結果が期待したものでない場合、誤りを認めることのできる、誠実なコミュニティでなければならない。氏は、DDDの適用可能性の限界も明確にすべきだ、すべてのプロジェクトがDDDで実施されるべきではない、とも考える。そのために氏は、コアドメインの重視、クリエイティブなコラボレーションによるモデルの模索、コンテキスト境界内における共通言語による会話、といった基本原則の集合としてDDDを定義している。氏の最後のことばは、次のとおりだ。共にDDDを実践し、新たなものにしていきましょう。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。