2022-05-02

テーブル設計の表現力

テーブル設計について学んだ。

テーブルの表現って？？単に、正規化を行って、１対多や多対多を意識して実装すれば全て解決うまく解決する？答えはNo..　例えばハンバーガー屋で商品テーブルからいろいろ組み合わせてオーダーしたい場合は？？ userがいて登録userと未登録userに振り分けたい場合は？？などなどシステムのusecaseで色々と要件が出てくる。これをただ、正規化して、１対多や多対多に設計や状態を管理するフラグカラムを立てて、対応できるか？？

対応できません！！！ (多分ですが)

テーブル設計の表現力を高めていくしかない！！！

どう表現力を高めるの？？？

オブジェクト思考を思い出してみよう。(コード内容はご愛嬌。。)

<?php

interface User {
  public function order();
}

//具象化する
class RegisteredUser implements User {
        public function order() {}
}

class AnonymousUser implements User {
        public function order() {}
}

// Userインターフェースを型に受けることで、対象のUserを意識しなくてよい。
class Order {
     private string $name;
     
     public function exec(User $user) {
            $user->order()
   }
}

抽象化することで、同じuserでも別々のuser を作ることができる。

それを使う側は特にどんなUserかは意識はしなくて良くなった。

これをテーブルに当てはめてみると！

userというテーブルがあり、それぞれに分岐した各userが存在する。かたやuserに紐付いているorderはuserがどっちのuserかは意識しなくて良くなった。

なんか疎結合にデータが管理することができる気がする！

どうやら、こういった設計パターンがあるらしい。吸収して、自分の引き出しを広げる取り組みを行って行かなければ。

テーブル設計にもいろんなパターンがあるんと、すごく感動しました！！今度はイミュータブルデータモデリングを学習しま〜す。

次こそ、監視について記事書かなきゃ。。。

2022-04-30

interfaceを用いいて抽象化するのは何がいい？？

今回はオブジェクト思考について学びました。前職でrepositoryパターンを用いて永久層の分離をおこなっていました。その際に、interfaceを用いて抽象化しそれ、具象化して実際のやりたい処理を記述していました。その時は機械的にinterfaceを用いていました。今回、interfaceを用いて抽象化することは何がメリットがあるのか？と考えました。キーワードはポリモフィズムかなと思います。

例えば、システムに出てきそうな、〜区分を表す様なものがあるとします。その区分を示すロジックを元に、あれやこれや処理を行いたい場合、大抵if文やswitch分を用いて処理を記述してしまうのではないでしょうか。これらの処理群は何らかのアクション(処理)と紐付いており密結合になりやすく、ロジックが散財し保守性が低下する要因になるよ考えます。これらの、複雑な条件分岐を排除し尚且つ疎結合にコードを管理したい場合のテクニックに使用できると思いました。下記の様なコードがあります。(クラス、メソッドの命名にご愛嬌で) 例えば、大人料金、子供料金の区分があったとします。それを interfaceで抽象化を行うことで、大人料金、子供料金の振る舞いを分けることに成功しました。 Fee抽象化することで、さまざまなタイプを具象化することができました。(ポリモフィズム)

<?php
interface Fee {
    public function yen();
    
    public function label();
}

class AdultFee implements Fee {
    public function yen() {
        return 1000;
    }
    
    public function label() {
        return 'adult';
    }
}

class ChildFee {
    public function yen() {
        return 500;
    }
    
    public function label() {
        return 'child';
    }
}

class Test {
    private Fee $fee;
    
    public function __construct(Fee $fee) {
        $this->fee = $fee;
    }
    
    public function status() {
        return $this->fee->label();
    }
}

$test = new Test(new AdultFee);
var_dump($test->status());

上記のコードから分かるように、Testクラスは特にFeeの振る舞いを気にせずとも使用ができます。 TestクラスがFeeに対すつ関心ごとを考えなくなり、疎結合なクラス間になったと思います。こうすることで必要なパーツを生成しつつ実際のロジック自体は具象化クラスに閉じ込めることができるメリットがあり、保守も容易になると考えました。

本日はここまで〜参考になった、本を載せておきます〜ではまた〜

俺SREエンジニアなんだけどな・・早く、監視の勉強しなきゃ・・

現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法

作者:増田亨
技術評論社

Amazon

2022-04-26

監視の種類

直近の出来事

こんにちは！最近、SREエンジニアとしてjobチェンジしました。jobチェンジしましたが、副業ではバックエンドエンジニアとして働いてます。前職ではパブリッククラウドを用いたインフラ構築の経験はありましたが、保守運用の経験はありませんでした。 SREエンジニアとしてデビューできたものの、インフラエンジニアとしての基礎作りがまだできていないと感じてます。そこで監視についてこれから勉強していこうと思います。

監視の種類

システム監視には外形監視と内部監視があります。

外形監視とはシステムの外部接続状況を監視すること。内部監視とはシステムの内部を監視することで、その中でもサービス稼働状況監視、システムリソース監視があります。

外形監視とは

外部からAPIを叩き、設定秒数間でレスポンスがあることを確認する監視方法。ユーザー視点でユーザーが体感している応答時間の遅延を把握することを目的している。また死活監視は同じような監視をするが、視点はシステム視点で、サーバーまでの通信の疎通がとれているかを監視する。また、監視基準はそれぞれあり、何秒以内とか、何秒続いたら見ないな設定を行う。今回は概要まで留めておくので、割愛させていただきます。

内部監視とは

リソース監視とはサーバーのCPU、メモリ、ディスクについて監視を行うこと。システム監視は、サービスの稼働状況を監視することを示しており、ポートは空いているのか、サービスに必要なプロセスは起動しているかポートは空いているのかを監視する

終わりに

今回は概要だけに絞ってみました。今後はもっと深ぼって、学んで行きます。 data dogも勉強しなきゃ。。

2022-02-11

classの責務について考えてみた

こんにちは、エンジニアになり１年が経ちました。

現在はバックエンド〜インフラまでの領域に従事しています。(フロントもやったりする)

僕が所属している会社ではバックエンドはlaravelを採用しています。最近はバックエンドのタスクに従事しており、日々勉強になっています。

所属会社の採用アーキテクチャーとして軽量DDD(？？)を採用しております。

そんなアーキテクチャの中でrepositoryパターンでqueryを作成した時に感じたことをブログに残しておこうと思います。

repositoryを採用するメリットとしては責務を分けることで、保守性を担保でき、また集約の中でinterfaceを定義することで集約ベースで明示的にメソッドを強制させ実装に対して制約を持たせることで一貫性を持たせることができると考えております。

集約というワードが出てきましたが、残念ながら弊社ではモデリングの部分を行なっていない為、laravelのmodelベースでrepositoryが分割されております。

そいった背景を踏まえて、modelベースでrepositoryを実装した時にあることを感じました。

それはlaravelの機能にscopeというmodelの機能を使用した時です。

先に話しておきますとscopeという機能は特定のModelクラスの中でscopeHogeHogeとメソッドを追加し引数にBuilderインスタンス、任意の引数を受け取り、ORMがかけちゃったりします。


public function scopeHoge(Builder $query, int $int)
{
    return $query->where('id', $int);
}

こんな記述です。今回行ったのが検索ボックスから検索queryを作成していた時に、ドキュメントを見ていたら、こんな機能があるな~ 思い記述してみました。

よしよし期待通りの動きをしていると、噛み締めながら実感していたところ、ある事に気づきました。

これmodelの中身をパッとみたときに、なんの為に実装したメソッドか分からなくない？？そしてこんなものを増やしていったら、model肥大しない？？

保守性を考慮するとrepositoryの関心ごとがmodelに漏れ出している事に気づきました。

実際この機能自体あまり使うところがないかもですが、この実装はやめました。

frameworkが提供してくれる機能は便利なものが多いです。ですが今回見てたく、なぜrepository層として分けているのか、クラスの責務とは？？を考えながら実装していく必要がある事に再度気がつかせてくれました。

最近ではDDDの勉強を個人で行なっています！！！

下記は、早く読んでおけば良かった本を掲載しておきます。

ではまた〜

現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法

作者:増田亨
技術評論社

Amazon