PythonでボトムアップDDD【値オブジェクト・エンティティ・ドメインサービスを利用する】 - Qiita
from __future__ import annotations import sqlite3 import unittest import uuid from dataclasses import dataclass @dataclass(frozen=True) class UserId: value: str @dataclass(frozen=True) class Username: value: str @dataclass(frozen=True) class FullName: first_name: str family_name: str @dataclass class User: id: UserId username: Username name: FullName def change_username(self, new_username: Usernam
PythonでボトムアップDDD 【エンティティ】 - Qiita
import dataclasses import unittest @dataclasses.dataclass(frozen=True) class FullName: full_name: str @dataclasses.dataclass class User: def __init__(self, full_name: FullName): self.full_name = full_name def change_full_name(self, new_name: FullName) -> None: if new_name is None: raise ValueError(f"{new_name} is invalid argument") self.full_name = new_name class TestUserEntity1(unittest.TestCase)
PythonでボトムアップDDD 【ドメインサービス】 - Qiita
バージョン Python 3.7.0 目次 ドメインサービスとは エンティティ自身に横断的な知識を実装 ドメインサービスに横断的な知識を実装 使う場面によっては別の案があるかも ドメインサービスとは ドメインサービスは、値オブジェクトとエンティティの横断的な知識を実装することが許されている。 エンティティ自身に横断的な知識を実装 エンティティに横断的な知識を持たせるように実装してみる。 ユーザ自身に他のユーザとの重複を判断させるのは、確かに違和感がある。 from __future__ import annotations import unittest import uuid from dataclasses import dataclass @dataclass(frozen=True) class UserId: value: str @dataclass(frozen=True)
オブジェクト指向で、データモデルを生成するクラスにはどんな名前をつけるべき？
オブジェクト指向の初学者です。データモデル？を生成するクラスの命名に困っています。 以下のような、モデルの生成・編集・削除などをするクラスのことはオブジェクト指向ではなんと呼ぶのでしょうか？また、こうしたオブジェクト指向のクラスの責任の分け方を学ぶためには何を参照するのがよいでしょうか。 # このクラスが"データモデル"です。 Class User(): self.name = "" self.age = 0 # このクラスの命名に悩んでいます。 Class UserFromDatabase(): self.db = DBClient() def make_user(): data = self.db.create({table: "user"}) return User(data) def get_user(id): data = self.db.get({table: "user",
Webアプリケーションの設計パターン / fujimisakari blog
Webアプリケーションを開発する上での設計パターンついて ある程度自分の中で知見がまとまったのでつらつら書いてみる。 ここで指してる設計パターンが何なのかというと、 機能を開発するための業務ロジック設計ではなく システム全体の構造の大枠を定義するための設計パターンになります。 なぜ設計が必要なのか設計方針を決めないまま開発していると、個々それぞれの実装経験やドメイン知識などが異なるので スキルに応じたフリーライティングとなり実装パターンがバラつきコードの可読性や保守性が下ってきてます。 これを防ぐために、システム構造の大枠の設計を定義します。 設計を導入することにより、どの機能はどこの書けばよいのかが明確になるので 誰が実装してもある程度同様の実装方針となります。 また、局所的な視点から見て不恰好なコードがあっても、 全体的な視点から見ればコードのレイアウトがきれいに整った構造になるので
Separation of business logic and data access in django
I am writing a project in Django and I see that 80% of the code is in the file models.py. This code is confusing and, after a certain time, I cease to understand what is really happening. Here is what bothers me: I find it ugly that my model level (which was supposed to be responsible only for the work with data from a database) is also sending email, walking on API to other services, etc. Also, I
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - hjwp/ddd-dynamic: Domain Driven Design in Python, Ruby and other dynamic languages resources
PythonでボトムアップDDD 【ユーザの登録・変更・削除・取得など】 - Qiita
PythonでボトムアップDDD 【テスト用のリポジトリ】 - Qiita
PythonでボトムアップDDD 【値オブジェクト】 - Qiita
PythonでボトムアップDDD 【リポジトリ】 - Qiita
一休の現在と、ここまでの道のり
