С помощью микросервисной архитектуры можно построить масштабируемое и гибкое приложение. Однако, если команда бессистемно использует этот подход в своей работе, то скоро столкнется с разочарованием и неконтролируемой сложностью. Избежать этого поможет DDD (Domain-Driven Design, предметно ориентированное проектирование). Не так давно я ничего не знал про этот подход, но сейчас я постоянно натыкаюсь на эту тему.
В этой статье мы построим с нуля онлайн-таверну, шаг за шагом исследуя различные части DDD. Надеюсь, разобраться с этим методом проектирования будет проще, если последовательно реализовывать небольшой учебный проект. Я выбрал для статьи именно такой способ повествования, потому что каждый раз, когда я читаю про DDD, моя голова буквально взрывается от разнообразия и сложности терминов.
Если вы не понимаете, о чём я, то эта схема, возможно, поможет понять мою боль.
Keywords in DDD — Graph from Eric Evans book Domain-Driven Design: Tackling Complexity in the Heart of Software
Первым делом я хочу отметить, что эта статья описывает моё представление о DDD, а реализация, которую я здесь покажу, основана на подходах, хорошо зарекомендовавших себя в Go-проектах, над которыми я работал; нельзя сказать, что описываемый здесь подход — признанный best practice. Буду придерживаться именования папок проекта согласно терминологии DDD. В реальных проектах я бы предпочёл другой способ, но так будет легче усвоить новые понятия. Шаг в сторону боевого проекта мы сделаем ближе к заключению: там я рефакторингом переработаю структуру и объясню, зачем это нужно.
Я не раз наблюдал горячие дискуссии в интернете о DDD и его правильном использовании. И каждый раз обращал внимание, что чаще всего люди забывают про основную цель DDD и зацикливаются на спорах о подробностях реализации. По-моему, главное — следовать предложенной Эвансом методологии, а не следить за тем, чтобы сущности были названы так или иначе.
DDD — это большая область знаний. Сейчас мы сосредоточимся на практической реализации подхода. Но сперва давайте пробежимся по основным аспектам предметно ориентированного проектирования.
Согласно DDD, команда разработки должна постоянно взаимодействовать с экспертами в предметной области (Subject Matter Experts, SME). Именно эти люди хранят знания, которые необходимо отразить в коде приложения. Например, если вам нужно создать приложение для торговли акциями, то было бы неплохо сперва побольше узнать о фондовом рынке из уст человека, обладающего большим опытом.
Архитектура должна отражать в коде структуру предметной области. Как именно — мы увидим, когда начнём писать наше приложение для управления таверной.
Данте и человек в высокой шляпе отлично погуляли и обсудили управление таверной. Данте узнал, что приходящих в таверну людей стоит называть клиентами, а не выпивохами. Также «шляпа» объяснил, что в таверне не только обслуживают клиентов, но и управляют сотрудниками, поставками и платежами.
Герои нашей истории поучаствовали в сессии моделирования предметной области: «шляпа» выступал в качестве эксперта, а Данте представлял команду инженеров. Такие беседы помогают построить правильную абстракцию над теми компонентами, которые нужны для создания модели.
В нашем случае основным доменом (Core/Root domain) будет таверна. Однако Шляпа упомянул и о других понятиях; так все члены команды, работающей над проектом, формируют универсальный язык (ubiquitous language), без которого общение сбивало бы с толку, а не помогало развитию.
Также выделились несколько поддоменов — важных областей, без которых нельзя представить работающую таверну. Поддомен — отдельная «вложенная» предметная область, которая используется для решения локального набора задач внутри основной предметной области.
mkdir ddd-go
go mod init github.com/percybolmer/ddd-go
Первым делом создадим папку domain, в которой будем хранить все необходимые поддомены. Но перед тем, как мы начнём работу с доменом, нам нужна другая папка. В учебных целях назовем её entity и положим туда сущности (entity) — структуры с идентификатором, которые могут изменять состояние.
Мы создадим две сущности: Person и Item. Я предпочитаю держать сущности в отдельном пакете, чтобы их можно было использовать из всех других доменов.
Для поддержания чистоты кода я делаю маленькие файлы и компактную структуру проекта, в которой легко ориентироваться. Так что рекомендую создать два отдельных файла для каждой сущности. Сейчас там будут только определения структур, но позже мы добавим и логику.
package entity
import "github.com/google/uuid"
// Person is a entity that represents a person in all Domains
type Person struct {
// ID is the identifier of the Entity, the ID is shared for all sub domains
ID uuid.UUID
Name string
Age int
}
package entity
import "github.com/google/uuid"
// Item represents a Item for all sub domains
type Item struct {
ID uuid.UUID
Name string
Description string
}
Перейдём к объектам-значениям (Value Objects) — неизменяемым структурам, которым не нужен идентификатор. Состояние таких объектов не изменяется после создания. Объекты-значения часто находятся внутри доменов и используются для описания конкретных аспектов в них. Сейчас создадим один объект-значение Transaction, после этого она уже не сможет изменить своё состояние. В реальном приложении ID для транзакции необходим, но для учебных целей этого примера достаточно.
package valueobject
import "time"
type Transaction struct {
// all values lowercase since they are immutable
amount int
from uuid.UUID
to uuid.UUID
createdAt time.Time
}
У агрегата в DDD должна быть только одна главная сущность (root entity). Тогда, ссылаясь на основную сущность, мы также будем ссылаться и на агрегат. Например, ID сущности Person может служить для однозначного определения агрегата Customer.
Давайте создадим папку aggregate, в которую положим файл customer.go. Там заведём новую структуру Customer, в которой будут все необходимые для представления клиента сущности. Обратите внимание, что все поля структуры начинаются с маленькой буквы (так мы запретим доступ к этим полям вне пакета структуры). Это осознанное решение, потому что агрегаты не должны предоставлять прямого доступа к своим данным. Также мы не добавляем никаких тегов в структуру, чтобы её нельзя было использовать для сериализации или сохранения в базу.
package aggregate
import (
"github.com/percybolmer/ddd-go/entity"
"github.com/percybolmer/ddd-go/valueobject"
)
// Customer is a aggregate that combines all entities needed to represent a customer
type Customer struct {
// person is the root entity of a customer
// which means the person.ID is the main identifier for this aggregate
person *entity.Person
// a customer can hold many products
products []*entity.Item
// a customer can perform many transactions
transactions []valueobject.Transaction
}
Все сущности заведены указателями, потому что они могут изменять своё состояние. И я хочу отразить это в коде.
DDD предлагает использовать фабрики для создания сложных агрегатов, репозиториев и сервисов (познакомимся с этими терминами далее). Мы реализуем фабрику NewCustomer. Происходящее внутри этой функции скрыто от вызывающего её кода и никак на него не влияет.
В реальном приложении я бы предпочел держать агрегат в папке domains/customer рядом с фабрикой, но подробнее об этом поговорим ниже.
package aggregate
import (
"errors"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/entity"
"github.com/percybolmer/ddd-go/valueobject"
)
var ErrInvalidPerson = errors.New("a customer has to have an valid person")
type Customer struct {
person *entity.Person
products []*entity.Item
transactions []valueobject.Transaction
}
// NewCustomer is a factory to create a new Customer aggregate
// It will validate that the name is not empty
func NewCustomer(name string) (Customer, error) {
if name == "" {
return Customer{}, ErrInvalidPerson
}
// Create a new person and generate ID
person := &entity.Person{
Name: name,
ID: uuid.New(),
}
// Create a customer object and initialize all the values to avoid nil pointer exceptions
return Customer{
person: person,
products: make([]*entity.Item, 0),
transactions: make([]valueobject.Transaction, 0),
}, nil
}
Сейчас фабрика взяла на себя всю ответственность по валидации входных данных, созданию нового ID и заданию всех начальных значений. Поскольку у нас появилась логика, пора добавить тесты. Добавляем файл customer_test.go в пакет aggregate.
package aggregate_test
import (
"testing"
"github.com/percybolmer/ddd-go/aggregate"
)
func TestCustomer_NewCustomer(t *testing.T) {
// Build our needed testcase data struct
type testCase struct {
test string
name string
expectedErr error
}
// Create new test cases
testCases := []testCase{
{
test: "Empty Name validation",
name: "",
expectedErr: aggregate.ErrInvalidPerson,
}, {
test: "Valid Name",
name: "Percy Bolmer",
expectedErr: nil,
},
}
for _, tc := range testCases {
// Run Tests
t.Run(tc.test, func(t *testing.T) {
// Create a new customer
_, err := aggregate.NewCustomer(tc.name)
// Check if the error matches the expected error
if err != tc.expectedErr {
t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
}
})
}
}
Начнём с создания файла repository.go внутри пакета domain/customer. Заведём там общие ошибки и интерфейс, который мы хотели бы видеть у хранилища.
// Package Customer holds all the domain logic for the customer domain.
package customer
import (
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
)
var (
ErrCustomerNotFound = errors.New("the customer was not found in the repository")
ErrFailedToAddCustomer = errors.New("failed to add the customer to the repository")
ErrUpdateCustomer = errors.New("failed to update the customer in the repository")
)
// CustomerRepository is a interface that defines the rules around what a customer repository
type CustomerRepository interface {
Get(uuid.UUID) (aggregate.Customer, error)
Add(aggregate.Customer) error
Update(aggregate.Customer) error
}
По моему опыту лучше держать каждую реализацию внутри собственной директории. Это позволит новым разработчикам легче вникать в проект, и искать нужные куски кода будет проще. Альтернативное решение — ограничиться файлом — на практике быстро приводит к замусориванию проекта.
mkdir memory
touch memory/memory.go
Перед работой над репозиторием нам нужно добавить немного функциональности Customer-у.
func (c *Customer) GetID() uuid.UUID {
return c.person.ID
}
func (c *Customer) SetID(id uuid.UUID) {
if c.person == nil {
c.person = &entity.Person{}
}
c.person.ID = id
}
func (c *Customer) SetName(name string) {
if c.person == nil {
c.person = &entity.Person{}
}
c.person.Name = name
}
func (c *Customer) GetName() string {
return c.person.Name
}
Создадим новую структуру, фабрику для неё и методы для реализации интерфейса.
// Package memory is a in-memory implementation of the customer repository
package memory
import (
"fmt"
"sync"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"github.com/percybolmer/ddd-go/domain/customer"
)
// MemoryRepository fulfills the CustomerRepository interface
type MemoryRepository struct {
customers map[uuid.UUID]aggregate.Customer
sync.Mutex
}
// New is a factory function to generate a new repository of customers
func New() *MemoryRepository {
return &MemoryRepository{
customers: make(map[uuid.UUID]aggregate.Customer),
}
}
// Get finds a customer by ID
func (mr *MemoryRepository) Get(id uuid.UUID) (aggregate.Customer, error) {
if customer, ok := mr.customers[id]; ok {
return customer, nil
}
return aggregate.Customer{}, customer.ErrCustomerNotFound
}
// Add will add a new customer to the repository
func (mr *MemoryRepository) Add(c aggregate.Customer) error {
if mr.customers == nil {
// Saftey check if customers is not create, shouldn't happen if using the Factory, but you never know
mr.Lock()
mr.customers = make(map[uuid.UUID]aggregate.Customer)
mr.Unlock()
}
// Make sure Customer isn't already in the repository
if _, ok := mr.customers[c.GetID()]; ok {
return fmt.Errorf("customer already exists: %w", customer.ErrFailedToAddCustomer)
}
mr.Lock()
mr.customers[c.GetID()] = c
mr.Unlock()
return nil
}
// Update will replace an existing customer information with the new customer information
func (mr *MemoryRepository) Update(c aggregate.Customer) error {
// Make sure Customer is in the repository
if _, ok := mr.customers[c.GetID()]; !ok {
return fmt.Errorf("customer does not exist: %w", customer.ErrUpdateCustomer)
}
mr.Lock()
mr.customers[c.GetID()] = c
mr.Unlock()
return nil
}
Как всегда, необходимо добавить тесты. И хочется отметить удобство репозиториев в том числе и при написании тестов: очень просто заменить реальный репозиторий на тестовый, который воспроизведёт условия возникновения багов.
import (
"testing"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"github.com/percybolmer/ddd-go/domain/customer"
)
func TestMemory_GetCustomer(t *testing.T) {
type testCase struct {
name string
id uuid.UUID
expectedErr error
}
// Create a fake customer to add to repository
cust, err := aggregate.NewCustomer("Percy")
if err != nil {
t.Fatal(err)
}
id := cust.GetID()
// Create the repo to use, and add some test Data to it for testing
// Skip Factory for this
repo := MemoryRepository{
customers: map[uuid.UUID]aggregate.Customer{
id: cust,
},
}
testCases := []testCase{
{
name: "No Customer By ID",
id: uuid.MustParse("f47ac10b-58cc-0372-8567-0e02b2c3d479"),
expectedErr: customer.ErrCustomerNotFound,
}, {
name: "Customer By ID",
id: id,
expectedErr: nil,
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
_, err := repo.Get(tc.id)
if err != tc.expectedErr {
t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
}
})
}
}
func TestMemory_AddCustomer(t *testing.T) {
type testCase struct {
name string
cust string
expectedErr error
}
testCases := []testCase{
{
name: "Add Customer",
cust: "Percy",
expectedErr: nil,
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
repo := MemoryRepository{
customers: map[uuid.UUID]aggregate.Customer{},
}
cust, err := aggregate.NewCustomer(tc.cust)
if err != nil {
t.Fatal(err)
}
err = repo.Add(cust)
if err != tc.expectedErr {
t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
}
found, err := repo.Get(cust.GetID())
if err != nil {
t.Fatal(err)
}
if found.GetID() != cust.GetID() {
t.Errorf("Expected %v, got %v", cust.GetID(), found.GetID())
}
})
}
}
Отлично, первый репозиторий готов. Помните, что нужно держать его тесно связанным с соответствующим доменом (поддерживаем высокую сопряжённость, high cohesion). Сейчас репозиторий управляет только одним агрегатом Customer, так и должно быть. Не стоит добавлять сюда управление другими агрегатами, ведь мы хотим сохранять слабую связность (loose coupling).
Но как нам тогда реализовывать логику работы таверны, если нельзя полагаться на один Customer Repository? Скоро мы начнём собирать вместе разные репозитории и выстраивать процесс работы таверны.
Обычно сервисы имеют доступ ко всем репозиториям, которые необходимы им для исполнения заданной бизнес-логики: Order, Api или Billing. Прелесть ещё заключается в том, что сервисы можно помещать внутрь других сервисов.
Все сервисы будем держать в папке services. Начнём с файла order.go и OrderService, который будет управлять заказами в таверне. У нас пока нехватает некоторых доменов, так что заведём CustomerRepository, а остальные добавим позже.
// Package services holds all the services that connects repositories into a business flow
package services
import "github.com/percybolmer/ddd-go/domain/customer"
// OrderConfiguration is an alias for a function that will take in a pointer to an OrderService and modify it
type OrderConfiguration func(os *OrderService) error
type OrderService struct {
customers customer.CustomerRepository
}
// NewOrderService takes a variable amount of OrderConfiguration functions and returns a new OrderService
// Each OrderConfiguration will be called in the order they are passed in
func NewOrderService(cfgs ...OrderConfiguration) (*OrderService, error) {
os := &OrderService{}
// Apply all Configurations passed in
for _, cfg := range cfgs {
err := cfg(os)
if err != nil {
return nil, err
}
}
return os, nil
}
// WithCustomerRepository applies a given customer repository to the OrderService
func WithCustomerRepository(cr customer.CustomerRepository) OrderConfiguration {
// return a function that matches the OrderConfiguration alias,
// You need to return this so that the parent function can take in all the needed parameters
return func(os *OrderService) error {
os.customers = cr
return nil
}
}
// WithMemoryCustomerRepository applies a memory customer repository to the OrderService
func WithMemoryCustomerRepository() OrderConfiguration {
// Create the memory repo, if we needed parameters, such as connection strings they could be inputted here
cr := memory.New()
return WithCustomerRepository(cr)
}
// CreateOrder will chain together all repositories to create a order for a customer
func (o *OrderService) CreateOrder(customerID uuid.UUID, productIDs []uuid.UUID) error {
// Get the customer
c, err := o.customers.Get(customerID)
if err != nil {
return err
}
// Get each Product, Ouchie, We need a ProductRepository
return nil
}
Упс, в нашей таверне нечего продавать. Но мы уже знаем, как это исправить: необходимо создать репозиторий для предлагаемых в таверне блюд и напитков.
Создадим новый агрегат Product и фабрику для него.
// File: product.go
// Product is an aggregate that represents a product.
package aggregate
import (
"errors"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/entity"
)
var ErrMissingValues = errors.New("missing values")
// Product is a aggregate that combines item with a price and quantity
type Product struct {
// item is the root entity which is an item
item *entity.Item
price float64
// Quantity is the number of products in stock
quantity int
}
func NewProduct(name, description string, price float64) (Product, error) {
if name == "" || description == "" {
return Product{}, ErrMissingValues
}
return Product{
item: &entity.Item{
ID: uuid.New(),
Name: name,
Description: description,
},
price: price,
quantity: 0,
}, nil
}
func (p Product) GetID() uuid.UUID {
return p.item.ID
}
func (p Product) GetItem() *entity.Item {
return p.item
}
func (p Product) GetPrice() float64 {
return p.price
}
Обязательно добавим тесты, чтобы убедиться в правильности работы кода.
package aggregate_test
import (
"testing"
"github.com/percybolmer/ddd-go/aggregate"
)
func TestProduct_NewProduct(t *testing.T) {
type testCase struct {
test string
name string
description string
price float64
expectedErr error
}
testCases := []testCase{
{
test: "should return error if name is empty",
name: "",
expectedErr: aggregate.ErrMissingValues,
},
{
test: "validvalues",
name: "test",
description: "test",
price: 1.0,
expectedErr: nil,
},
}
for _, tc := range testCases {
t.Run(tc.test, func(t *testing.T) {
_, err := aggregate.NewProduct(tc.name, tc.description, tc.price)
if err != tc.expectedErr {
t.Errorf("Expected error: %v, got: %v", tc.expectedErr, err)
}
})
}
}
В файле domain/product/repository.go определим интерфейс ProductRepository, реализация которого обеспечит доступ к товарам.
// Package product holds the repository and the implementations for a ProductRepository
package product
import (
"errors"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
)
var (
ErrProductNotFound = errors.New("the product was not found")
ErrProductAlreadyExist = errors.New("the product already exists")
)
// ProductRepository is the repository interface to fulfill to use the product aggregate
type ProductRepository interface {
GetAll() ([]aggregate.Product, error)
GetByID(id uuid.UUID) (aggregate.Product, error)
Add(product aggregate.Product) error
Update(product aggregate.Product) error
Delete(id uuid.UUID) error
}
Как и в случае с репозиторием клиентов, реализуем хранилище в оперативной памяти: для этого в домене product создадим папку memory.
// Package memory is a in memory implementation of the ProductRepository interface.
package memory
import (
"sync"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"github.com/percybolmer/ddd-go/domain/product"
)
type MemoryProductRepository struct {
products map[uuid.UUID]aggregate.Product
sync.Mutex
}
// New is a factory function to generate a new repository of customers
func New() *MemoryProductRepository {
return &MemoryProductRepository{
products: make(map[uuid.UUID]aggregate.Product),
}
}
// GetAll returns all products as a slice
// Yes, it never returns an error, but
// A database implementation could return an error for instance
func (mpr *MemoryProductRepository) GetAll() ([]aggregate.Product, error) {
// Collect all Products from map
var products []aggregate.Product
for _, product := range mpr.products {
products = append(products, product)
}
return products, nil
}
// GetByID searches for a product based on it's ID
func (mpr *MemoryProductRepository) GetByID(id uuid.UUID) (aggregate.Product, error) {
if product, ok := mpr.products[uuid.UUID(id)]; ok {
return product, nil
}
return aggregate.Product{}, product.ErrProductNotFound
}
// Add will add a new product to the repository
func (mpr *MemoryProductRepository) Add(newprod aggregate.Product) error {
mpr.Lock()
defer mpr.Unlock()
if _, ok := mpr.products[newprod.GetID()]; ok {
return product.ErrProductAlreadyExist
}
mpr.products[newprod.GetID()] = newprod
return nil
}
// Update will change all values for a product based on it's ID
func (mpr *MemoryProductRepository) Update(upprod aggregate.Product) error {
mpr.Lock()
defer mpr.Unlock()
if _, ok := mpr.products[upprod.GetID()]; !ok {
return product.ErrProductNotFound
}
mpr.products[upprod.GetID()] = upprod
return nil
}
// Delete remove an product from the repository
func (mpr *MemoryProductRepository) Delete(id uuid.UUID) error {
mpr.Lock()
defer mpr.Unlock()
if _, ok := mpr.products[id]; !ok {
return product.ErrProductNotFound
}
delete(mpr.products, id)
return nil
}
Как всегда, добавим тесты.
package memory
import (
"testing"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"github.com/percybolmer/ddd-go/domain/product"
)
func TestMemoryProductRepository_Add(t *testing.T) {
repo := New()
product, err := aggregate.NewProduct("Beer", "Good for you're health", 1.99)
if err != nil {
t.Error(err)
}
repo.Add(product)
if len(repo.products) != 1 {
t.Errorf("Expected 1 product, got %d", len(repo.products))
}
}
func TestMemoryProductRepository_Get(t *testing.T) {
repo := New()
existingProd, err := aggregate.NewProduct("Beer", "Good for you're health", 1.99)
if err != nil {
t.Error(err)
}
repo.Add(existingProd)
if len(repo.products) != 1 {
t.Errorf("Expected 1 product, got %d", len(repo.products))
}
type testCase struct {
name string
id uuid.UUID
expectedErr error
}
testCases := []testCase{
{
name: "Get product by id",
id: existingProd.GetID(),
expectedErr: nil,
}, {
name: "Get non-existing product by id",
id: uuid.New(),
expectedErr: product.ErrProductNotFound,
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
_, err := repo.GetByID(tc.id)
if err != tc.expectedErr {
t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
}
})
}
}
func TestMemoryProductRepository_Delete(t *testing.T) {
repo := New()
existingProd, err := aggregate.NewProduct("Beer", "Good for you're health", 1.99)
if err != nil {
t.Error(err)
}
repo.Add(existingProd)
if len(repo.products) != 1 {
t.Errorf("Expected 1 product, got %d", len(repo.products))
}
err = repo.Delete(existingProd.GetID())
if err != nil {
t.Error(err)
}
if len(repo.products) != 0 {
t.Errorf("Expected 0 products, got %d", len(repo.products))
}
}
Добавим OrderService-у возможность использовать ProductRepository с помощью соответствующей опции.
// OrderService is a implementation of the OrderService
type OrderService struct {
customers customer.CustomerRepository
products product.ProductRepository
}
// WithMemoryProductRepository adds a in memory product repo and adds all input products
func WithMemoryProductRepository(products []aggregate.Product) OrderConfiguration {
return func(os *OrderService) error {
// Create the memory repo, if we needed parameters, such as connection strings they could be inputted here
pr := prodmemory.New()
// Add Items to repo
for _, p := range products {
err := pr.Add(p)
if err != nil {
return err
}
}
os.products = pr
return nil
}
}
Давайте прокачаем метод CreateOrder: теперь можно искать заказанные продукты и возвращать суммарную их стоимость.
// CreateOrder will chain together all repositories to create a order for a customer
// will return the collected price of all Products
func (o *OrderService) CreateOrder(customerID uuid.UUID, productIDs []uuid.UUID) (float64, error) {
c, err := o.customers.Get(customerID)
if err != nil {
return 0, err
}
// Get each Product, Ouchie, We need a ProductRepository
var products []aggregate.Product
var price float64
for _, id := range productIDs {
p, err := o.products.GetByID(id)
if err != nil {
return 0, err
}
products = append(products, p)
price += p.GetPrice()
}
// All Products exists in store, now we can create the order
log.Printf("Customer: %s has ordered %d products", c.GetID(), len(products))
return price, nil
}
Поправим тесты order_test.go, чтобы сервис создавался с обоими репозиториями.
package services
import (
"testing"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
)
func init_products(t *testing.T) []aggregate.Product {
beer, err := aggregate.NewProduct("Beer", "Healthy Beverage", 1.99)
if err != nil {
t.Error(err)
}
peenuts, err := aggregate.NewProduct("Peenuts", "Healthy Snacks", 0.99)
if err != nil {
t.Error(err)
}
wine, err := aggregate.NewProduct("Wine", "Healthy Snacks", 0.99)
if err != nil {
t.Error(err)
}
products := []aggregate.Product{
beer, peenuts, wine,
}
return products
}
func TestOrder_NewOrderService(t *testing.T) {
// Create a few products to insert into in memory repo
products := init_products(t)
os, err := NewOrderService(
WithMemoryCustomerRepository(),
WithMemoryProductRepository(products),
)
if err != nil {
t.Error(err)
}
// Add Customer
cust, err := aggregate.NewCustomer("Percy")
if err != nil {
t.Error(err)
}
err = os.customers.Add(cust)
if err != nil {
t.Error(err)
}
// Perform Order for one beer
order := []uuid.UUID{
products[0].GetID(),
}
_, err = os.CreateOrder(cust.GetID(), order)
if err != nil {
t.Error(err)
}
}
package services
import (
"log"
"github.com/google/uuid"
)
// TavernConfiguration is an alias that takes a pointer and modifies the Tavern
type TavernConfiguration func(os *Tavern) error
type Tavern struct {
// orderservice is used to handle orders
OrderService *OrderService
// BillingService is used to handle billing
// This is up to you to implement
BillingService interface{}
}
// NewTavern takes a variable amount of TavernConfigurations and builds a Tavern
func NewTavern(cfgs ...TavernConfiguration) (*Tavern, error) {
// Create the Tavern
t := &Tavern{}
// Apply all Configurations passed in
for _, cfg := range cfgs {
// Pass the service into the configuration function
err := cfg(t)
if err != nil {
return nil, err
}
}
return t, nil
}
// WithOrderService applies a given OrderService to the Tavern
func WithOrderService(os *OrderService) TavernConfiguration {
// return a function that matches the TavernConfiguration signature
return func(t *Tavern) error {
t.OrderService = os
return nil
}
}
// Order performs an order for a customer
func (t *Tavern) Order(customer uuid.UUID, products []uuid.UUID) error {
price, err := t.OrderService.CreateOrder(customer, products)
if err != nil {
return err
}
log.Printf("Bill the Customer: %0.0f", price)
// Bill the customer
// err = t.BillingService.Bill(customer, price)
return nil
}
Чтобы попробовать сервис в деле, можно создать тест.
package services
import (
"testing"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
)
func Test_Tavern(t *testing.T) {
// Create OrderService
products := init_products(t)
os, err := NewOrderService(
WithMemoryCustomerRepository(),
WithMemoryProductRepository(products),
)
if err != nil {
t.Error(err)
}
tavern, err := NewTavern(WithOrderService(os))
if err != nil {
t.Error(err)
}
cust, err := aggregate.NewCustomer("Percy")
if err != nil {
t.Error(err)
}
err = os.customers.Add(cust)
if err != nil {
t.Error(err)
}
order := []uuid.UUID{
products[0].GetID(),
}
// Execute Order
err = tavern.Order(cust.GetID(), order)
if err != nil {
t.Error(err)
}
}
Давайте теперь заменим реализацию CustomerRepository. Выберем в качестве реального хранилища MongoDB. Тут паттерн «репозиторий» засияет во всей красе. Я очень ценю возможность заменить с такой лёгкостью репозиторий.
Хочется отметить внутреннюю структуру mongoCustomer, которая используется непосредственно для управления данными из MongoDB. Мы не стали использовать для этих целей уже готовый aggregate.Customer, потому что это связало бы агрегат и хранилище (в агрегат просочились бы bson-теги и заменить при желании хранилище стало бы сложно). А мы, наоборот, хотим, чтобы репозиторий полностью отвечал за (де)сериализацию данных, не распространяя свои внутренние сущности вовне. Поэтому мы и не использовали непосредственно в структуре агрегата теги json или bson. Перегонять же из внутренней структуры в агрегат и наоборот будем с помощью функций.
// Mongo is a mongo implementation of the Customer Repository
package mongo
import (
"context"
"time"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"go.mongodb.org/mongo-driver/bson"
"go.mongodb.org/mongo-driver/mongo"
"go.mongodb.org/mongo-driver/mongo/options"
)
type MongoRepository struct {
db *mongo.Database
// customer is used to store customers
customer *mongo.Collection
}
// mongoCustomer is an internal type that is used to store a CustomerAggregate
// we make an internal struct for this to avoid coupling this mongo implementation to the customeraggregate.
// Mongo uses bson so we add tags for that
type mongoCustomer struct {
ID uuid.UUID `bson:"id"`
Name string `bson:"name"`
}
// NewFromCustomer takes in a aggregate and converts into internal structure
func NewFromCustomer(c aggregate.Customer) mongoCustomer {
return mongoCustomer{
ID: c.GetID(),
Name: c.GetName(),
}
}
// ToAggregate converts into a aggregate.Customer
// this could validate all values present etc
func (m mongoCustomer) ToAggregate() aggregate.Customer {
c := aggregate.Customer{}
c.SetID(m.ID)
c.SetName(m.Name)
return c
}
// Create a new mongodb repository
func New(ctx context.Context, connectionString string) (*MongoRepository, error) {
client, err := mongo.Connect(ctx, options.Client().ApplyURI(connectionString))
if err != nil {
return nil, err
}
// Find Metabot DB
db := client.Database("ddd")
customers := db.Collection("customers")
return &MongoRepository{
db: db,
customer: customers,
}, nil
}
func (mr *MongoRepository) Get(id uuid.UUID) (aggregate.Customer, error) {
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
result := mr.customer.FindOne(ctx, bson.M{"id": id})
var c mongoCustomer
err := result.Decode(&c)
if err != nil {
return aggregate.Customer{}, err
}
// Convert to aggregate
return c.ToAggregate(), nil
}
func (mr *MongoRepository) Add(c aggregate.Customer) error {
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
internal := NewFromCustomer(c)
_, err := mr.customer.InsertOne(ctx, internal)
if err != nil {
return err
}
return nil
}
func (mr *MongoRepository) Update(c aggregate.Customer) error {
panic("to implement")
}
Далее нужно добавить функцию-конфигуратор для внедрения нового репозитория в OrderService.
func WithMongoCustomerRepository(connectionString string) OrderConfiguration {
return func(os *OrderService) error {
// Create the mongo repo, if we needed parameters, such as connection strings they could be inputted here
cr, err := mongo.New(context.Background(), connectionString)
if err != nil {
return err
}
os.customers = cr
return nil
}
}
Теперь можно с лёгкостью заменить один репозиторий на другой.
func Test_MongoTavern(t *testing.T) {
// Create OrderService
products := init_products(t)
os, err := NewOrderService(
WithMongoCustomerRepository("mongodb://localhost:27017"),
WithMemoryProductRepository(products),
)
if err != nil {
t.Error(err)
}
tavern, err := NewTavern(WithOrderService(os))
if err != nil {
t.Error(err)
}
cust, err := aggregate.NewCustomer("Percy")
if err != nil {
t.Error(err)
}
err = os.customers.Add(cust)
if err != nil {
t.Error(err)
}
order := []uuid.UUID{
products[0].GetID(),
}
// Execute Order
err = tavern.Order(cust.GetID(), order)
if err != nil {
t.Error(err)
}
}
Теперь наша таверна умеет работать как с in-memory хранилищем, так и с MongoDB.
Вот мы и познакомились с основами предметно-ориентированного проектирования. Основные термины, с которыми мы поработали:
Не забудьте, что в этом случае придётся заново выполнить go mod init и переименовать импорты.
Наконец, перед нами итоговый вид проекта.
Заключительный совет, который я хочу вам дать: держите в проекте папку cmd с пакетами запуска приложений внутри проекта. Это может быть запуск API, consumer-а, однократных скриптов и миграций. В папке cmd следует сосредоточить использование инструментов для запуска приложения из командной строки и разнообразные настройки при инициализации.
habr.com
В этой статье мы построим с нуля онлайн-таверну, шаг за шагом исследуя различные части DDD. Надеюсь, разобраться с этим методом проектирования будет проще, если последовательно реализовывать небольшой учебный проект. Я выбрал для статьи именно такой способ повествования, потому что каждый раз, когда я читаю про DDD, моя голова буквально взрывается от разнообразия и сложности терминов.
Если вы не понимаете, о чём я, то эта схема, возможно, поможет понять мою боль.
Первым делом я хочу отметить, что эта статья описывает моё представление о DDD, а реализация, которую я здесь покажу, основана на подходах, хорошо зарекомендовавших себя в Go-проектах, над которыми я работал; нельзя сказать, что описываемый здесь подход — признанный best practice. Буду придерживаться именования папок проекта согласно терминологии DDD. В реальных проектах я бы предпочёл другой способ, но так будет легче усвоить новые понятия. Шаг в сторону боевого проекта мы сделаем ближе к заключению: там я рефакторингом переработаю структуру и объясню, зачем это нужно.
Я не раз наблюдал горячие дискуссии в интернете о DDD и его правильном использовании. И каждый раз обращал внимание, что чаще всего люди забывают про основную цель DDD и зацикливаются на спорах о подробностях реализации. По-моему, главное — следовать предложенной Эвансом методологии, а не следить за тем, чтобы сущности были названы так или иначе.
DDD — это большая область знаний. Сейчас мы сосредоточимся на практической реализации подхода. Но сперва давайте пробежимся по основным аспектам предметно ориентированного проектирования.
Что такое DDD
Domain-Driven Design — это способ структурирования знаний и создания упрощенной модели той предметной области (домена, domain), к которой относится разрабатываемое ПО. В первую очередь необходимо изучить предметную область. Ею может быть любая задача или проблема, решению которой должна способствовать создаваемая программа. При этом приложение следует конструировать так, чтобы его архитектура отражала структуру предметной области.Согласно DDD, команда разработки должна постоянно взаимодействовать с экспертами в предметной области (Subject Matter Experts, SME). Именно эти люди хранят знания, которые необходимо отразить в коде приложения. Например, если вам нужно создать приложение для торговли акциями, то было бы неплохо сперва побольше узнать о фондовом рынке из уст человека, обладающего большим опытом.
Архитектура должна отражать в коде структуру предметной области. Как именно — мы увидим, когда начнём писать наше приложение для управления таверной.
Путешествие гофера в DDD
Начнём с небольшой истории про гофера Данте, который хочет создать виртуальную таверну. Данте знает, как писать код, но понятия не имеет, как управлять таверной. В тот день, когда Данте решает начать работу над программой, у него возникает вопрос: с чего начать? Он выходит на прогулку, обдумывая свои планы. Пока Данте стоит на светофоре, к нему подходит человек в высокой шляпе и говорит: «Похоже, вы чем-то обеспокоены, молодой человек. Не нужна ли вам помощь в создании таверны?».Данте и человек в высокой шляпе отлично погуляли и обсудили управление таверной. Данте узнал, что приходящих в таверну людей стоит называть клиентами, а не выпивохами. Также «шляпа» объяснил, что в таверне не только обслуживают клиентов, но и управляют сотрудниками, поставками и платежами.
Домен, модель, универсальный язык и поддомены
Надеюсь, вам понравилась история про Данте, ведь я написал её не просто так. Она послужит нам контекстом, который позволит проще объяснить некоторые ключевые понятия.Герои нашей истории поучаствовали в сессии моделирования предметной области: «шляпа» выступал в качестве эксперта, а Данте представлял команду инженеров. Такие беседы помогают построить правильную абстракцию над теми компонентами, которые нужны для создания модели.
В нашем случае основным доменом (Core/Root domain) будет таверна. Однако Шляпа упомянул и о других понятиях; так все члены команды, работающей над проектом, формируют универсальный язык (ubiquitous language), без которого общение сбивало бы с толку, а не помогало развитию.
Также выделились несколько поддоменов — важных областей, без которых нельзя представить работающую таверну. Поддомен — отдельная «вложенная» предметная область, которая используется для решения локального набора задач внутри основной предметной области.
Код DDD-приложения на Go
Сущности и объекты-значения
Пора начинать писать код нашего приложения, у нас есть всё, что необходимо. Начнём с создания окружения проекта.mkdir ddd-go
go mod init github.com/percybolmer/ddd-go
Первым делом создадим папку domain, в которой будем хранить все необходимые поддомены. Но перед тем, как мы начнём работу с доменом, нам нужна другая папка. В учебных целях назовем её entity и положим туда сущности (entity) — структуры с идентификатором, которые могут изменять состояние.
Мы создадим две сущности: Person и Item. Я предпочитаю держать сущности в отдельном пакете, чтобы их можно было использовать из всех других доменов.
Для поддержания чистоты кода я делаю маленькие файлы и компактную структуру проекта, в которой легко ориентироваться. Так что рекомендую создать два отдельных файла для каждой сущности. Сейчас там будут только определения структур, но позже мы добавим и логику.
import "github.com/google/uuid"
// Person is a entity that represents a person in all Domains
type Person struct {
// ID is the identifier of the Entity, the ID is shared for all sub domains
ID uuid.UUID
Name string
Age int
}
package entity
import "github.com/google/uuid"
// Item represents a Item for all sub domains
type Item struct {
ID uuid.UUID
Name string
Description string
}
Перейдём к объектам-значениям (Value Objects) — неизменяемым структурам, которым не нужен идентификатор. Состояние таких объектов не изменяется после создания. Объекты-значения часто находятся внутри доменов и используются для описания конкретных аспектов в них. Сейчас создадим один объект-значение Transaction, после этого она уже не сможет изменить своё состояние. В реальном приложении ID для транзакции необходим, но для учебных целей этого примера достаточно.
package valueobject
import "time"
type Transaction struct {
// all values lowercase since they are immutable
amount int
from uuid.UUID
to uuid.UUID
createdAt time.Time
}
Агрегаты: комбинированные сущности и объекты-значения
Агрегат (Aggregate) — это набор скомбинированных сущностей и объектов-значений. В нашем случае можно начать с создания агрегата Customer. Роль агрегатов — быть объектом бизнес-логики. Они не дают прямого доступа к хранимым сущностям, которых может быть несколько. Например, для определения покупателя нам потребуется не только сущность Person, но и Products вместе с Transactions.У агрегата в DDD должна быть только одна главная сущность (root entity). Тогда, ссылаясь на основную сущность, мы также будем ссылаться и на агрегат. Например, ID сущности Person может служить для однозначного определения агрегата Customer.
Давайте создадим папку aggregate, в которую положим файл customer.go. Там заведём новую структуру Customer, в которой будут все необходимые для представления клиента сущности. Обратите внимание, что все поля структуры начинаются с маленькой буквы (так мы запретим доступ к этим полям вне пакета структуры). Это осознанное решение, потому что агрегаты не должны предоставлять прямого доступа к своим данным. Также мы не добавляем никаких тегов в структуру, чтобы её нельзя было использовать для сериализации или сохранения в базу.
package aggregate
import (
"github.com/percybolmer/ddd-go/entity"
"github.com/percybolmer/ddd-go/valueobject"
)
// Customer is a aggregate that combines all entities needed to represent a customer
type Customer struct {
// person is the root entity of a customer
// which means the person.ID is the main identifier for this aggregate
person *entity.Person
// a customer can hold many products
products []*entity.Item
// a customer can perform many transactions
transactions []valueobject.Transaction
}
Все сущности заведены указателями, потому что они могут изменять своё состояние. И я хочу отразить это в коде.
Фабрики: способ сокрытия сложной логики
До сих пор мы с вами только заводили различные сущности, объекты-значения и агрегаты. Настало время реализовать часть бизнес-логики, и начнём мы с фабрик (factories). Паттерн «фабрика» используется для сокрытия сложной логики внутри функций, которые создают желаемые экземпляры объектов. При этом вызывающий такую функцию код ничего не знает о деталях реализации и особенностях создания желаемого объекта.Фабрика — очень распространенный паттерн, который можно использовать и за рамками DDD-приложений, и вы, скорее всего, уже делали это не один раз.
DDD предлагает использовать фабрики для создания сложных агрегатов, репозиториев и сервисов (познакомимся с этими терминами далее). Мы реализуем фабрику NewCustomer. Происходящее внутри этой функции скрыто от вызывающего её кода и никак на него не влияет.
В реальном приложении я бы предпочел держать агрегат в папке domains/customer рядом с фабрикой, но подробнее об этом поговорим ниже.
package aggregate
import (
"errors"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/entity"
"github.com/percybolmer/ddd-go/valueobject"
)
var ErrInvalidPerson = errors.New("a customer has to have an valid person")
type Customer struct {
person *entity.Person
products []*entity.Item
transactions []valueobject.Transaction
}
// NewCustomer is a factory to create a new Customer aggregate
// It will validate that the name is not empty
func NewCustomer(name string) (Customer, error) {
if name == "" {
return Customer{}, ErrInvalidPerson
}
// Create a new person and generate ID
person := &entity.Person{
Name: name,
ID: uuid.New(),
}
// Create a customer object and initialize all the values to avoid nil pointer exceptions
return Customer{
person: person,
products: make([]*entity.Item, 0),
transactions: make([]valueobject.Transaction, 0),
}, nil
}
Сейчас фабрика взяла на себя всю ответственность по валидации входных данных, созданию нового ID и заданию всех начальных значений. Поскольку у нас появилась логика, пора добавить тесты. Добавляем файл customer_test.go в пакет aggregate.
package aggregate_test
import (
"testing"
"github.com/percybolmer/ddd-go/aggregate"
)
func TestCustomer_NewCustomer(t *testing.T) {
// Build our needed testcase data struct
type testCase struct {
test string
name string
expectedErr error
}
// Create new test cases
testCases := []testCase{
{
test: "Empty Name validation",
name: "",
expectedErr: aggregate.ErrInvalidPerson,
}, {
test: "Valid Name",
name: "Percy Bolmer",
expectedErr: nil,
},
}
for _, tc := range testCases {
// Run Tests
t.Run(tc.test, func(t *testing.T) {
// Create a new customer
_, err := aggregate.NewCustomer(tc.name)
// Check if the error matches the expected error
if err != tc.expectedErr {
t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
}
})
}
}
Но далеко с текущими возможностями таверны мы не уедем. Пора взглянуть на самый лучший паттерн, который мне известен.
Репозитории
DDD говорит, что репозитории должны хранить и управлять агрегатами. Изучив этот паттерн, я сразу понял, что никогда не перестану его использовать. Он полагается на сокрытие взаимодействия с хранилищем за интерфейсом реализации. Главное преимущество такого подхода заключается в возможности заменить реализацию без опасения что-либо сломать. Мы можем ограничиться локальным хранилищем на период разработки и переключиться позже на MongoDB, например, без необходимости переписывать что-либо кроме самого кода взаимодействия с хранилищем. Это поможет не только при замене вендора, но и при тестировании: можно с лёгкостью замокать хранилище с помощью новой реализации интерфейса.Начнём с создания файла repository.go внутри пакета domain/customer. Заведём там общие ошибки и интерфейс, который мы хотели бы видеть у хранилища.
// Package Customer holds all the domain logic for the customer domain.
package customer
import (
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
)
var (
ErrCustomerNotFound = errors.New("the customer was not found in the repository")
ErrFailedToAddCustomer = errors.New("failed to add the customer to the repository")
ErrUpdateCustomer = errors.New("failed to update the customer in the repository")
)
// CustomerRepository is a interface that defines the rules around what a customer repository
type CustomerRepository interface {
Get(uuid.UUID) (aggregate.Customer, error)
Add(aggregate.Customer) error
Update(aggregate.Customer) error
}
Далее хочется написать реализацию определённого ранее интерфейса. И начну я с хранилища в памяти. В конце статьи посмотрим, как заменить хранилище реальным без нарушения совместимости с соседними частями приложения.
По моему опыту лучше держать каждую реализацию внутри собственной директории. Это позволит новым разработчикам легче вникать в проект, и искать нужные куски кода будет проще. Альтернативное решение — ограничиться файлом — на практике быстро приводит к замусориванию проекта.
mkdir memory
touch memory/memory.go
Перед работой над репозиторием нам нужно добавить немного функциональности Customer-у.
func (c *Customer) GetID() uuid.UUID {
return c.person.ID
}
func (c *Customer) SetID(id uuid.UUID) {
if c.person == nil {
c.person = &entity.Person{}
}
c.person.ID = id
}
func (c *Customer) SetName(name string) {
if c.person == nil {
c.person = &entity.Person{}
}
c.person.Name = name
}
func (c *Customer) GetName() string {
return c.person.Name
}
Создадим новую структуру, фабрику для неё и методы для реализации интерфейса.
// Package memory is a in-memory implementation of the customer repository
package memory
import (
"fmt"
"sync"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"github.com/percybolmer/ddd-go/domain/customer"
)
// MemoryRepository fulfills the CustomerRepository interface
type MemoryRepository struct {
customers map[uuid.UUID]aggregate.Customer
sync.Mutex
}
// New is a factory function to generate a new repository of customers
func New() *MemoryRepository {
return &MemoryRepository{
customers: make(map[uuid.UUID]aggregate.Customer),
}
}
// Get finds a customer by ID
func (mr *MemoryRepository) Get(id uuid.UUID) (aggregate.Customer, error) {
if customer, ok := mr.customers[id]; ok {
return customer, nil
}
return aggregate.Customer{}, customer.ErrCustomerNotFound
}
// Add will add a new customer to the repository
func (mr *MemoryRepository) Add(c aggregate.Customer) error {
if mr.customers == nil {
// Saftey check if customers is not create, shouldn't happen if using the Factory, but you never know
mr.Lock()
mr.customers = make(map[uuid.UUID]aggregate.Customer)
mr.Unlock()
}
// Make sure Customer isn't already in the repository
if _, ok := mr.customers[c.GetID()]; ok {
return fmt.Errorf("customer already exists: %w", customer.ErrFailedToAddCustomer)
}
mr.Lock()
mr.customers[c.GetID()] = c
mr.Unlock()
return nil
}
// Update will replace an existing customer information with the new customer information
func (mr *MemoryRepository) Update(c aggregate.Customer) error {
// Make sure Customer is in the repository
if _, ok := mr.customers[c.GetID()]; !ok {
return fmt.Errorf("customer does not exist: %w", customer.ErrUpdateCustomer)
}
mr.Lock()
mr.customers[c.GetID()] = c
mr.Unlock()
return nil
}
Как всегда, необходимо добавить тесты. И хочется отметить удобство репозиториев в том числе и при написании тестов: очень просто заменить реальный репозиторий на тестовый, который воспроизведёт условия возникновения багов.
package memory
import (
"testing"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"github.com/percybolmer/ddd-go/domain/customer"
)
func TestMemory_GetCustomer(t *testing.T) {
type testCase struct {
name string
id uuid.UUID
expectedErr error
}
// Create a fake customer to add to repository
cust, err := aggregate.NewCustomer("Percy")
if err != nil {
t.Fatal(err)
}
id := cust.GetID()
// Create the repo to use, and add some test Data to it for testing
// Skip Factory for this
repo := MemoryRepository{
customers: map[uuid.UUID]aggregate.Customer{
id: cust,
},
}
testCases := []testCase{
{
name: "No Customer By ID",
id: uuid.MustParse("f47ac10b-58cc-0372-8567-0e02b2c3d479"),
expectedErr: customer.ErrCustomerNotFound,
}, {
name: "Customer By ID",
id: id,
expectedErr: nil,
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
_, err := repo.Get(tc.id)
if err != tc.expectedErr {
t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
}
})
}
}
func TestMemory_AddCustomer(t *testing.T) {
type testCase struct {
name string
cust string
expectedErr error
}
testCases := []testCase{
{
name: "Add Customer",
cust: "Percy",
expectedErr: nil,
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
repo := MemoryRepository{
customers: map[uuid.UUID]aggregate.Customer{},
}
cust, err := aggregate.NewCustomer(tc.cust)
if err != nil {
t.Fatal(err)
}
err = repo.Add(cust)
if err != tc.expectedErr {
t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
}
found, err := repo.Get(cust.GetID())
if err != nil {
t.Fatal(err)
}
if found.GetID() != cust.GetID() {
t.Errorf("Expected %v, got %v", cust.GetID(), found.GetID())
}
})
}
}
Отлично, первый репозиторий готов. Помните, что нужно держать его тесно связанным с соответствующим доменом (поддерживаем высокую сопряжённость, high cohesion). Сейчас репозиторий управляет только одним агрегатом Customer, так и должно быть. Не стоит добавлять сюда управление другими агрегатами, ведь мы хотим сохранять слабую связность (loose coupling).
Но как нам тогда реализовывать логику работы таверны, если нельзя полагаться на один Customer Repository? Скоро мы начнём собирать вместе разные репозитории и выстраивать процесс работы таверны.
Сервисы: реализуем бизнес-логику
Мы создали все эти сущности, агрегаты и репозитории, но до сих пор наш код не выглядит как цельное приложение. Поэтому нам нужен такой компонент как «сервис». Он свяжет все разрозненные компоненты в бизнес-логику, которая удовлетворит нуждам конкретного домена. В случае с таверной нам понадобится сервис Order, который будет связывать воедино репозитории (CustomerRepository и ProductRepository) для исполнения заказа.Обычно сервисы имеют доступ ко всем репозиториям, которые необходимы им для исполнения заданной бизнес-логики: Order, Api или Billing. Прелесть ещё заключается в том, что сервисы можно помещать внутрь других сервисов.
Все сервисы будем держать в папке services. Начнём с файла order.go и OrderService, который будет управлять заказами в таверне. У нас пока нехватает некоторых доменов, так что заведём CustomerRepository, а остальные добавим позже.
// Package services holds all the services that connects repositories into a business flow
package services
import "github.com/percybolmer/ddd-go/domain/customer"
// OrderConfiguration is an alias for a function that will take in a pointer to an OrderService and modify it
type OrderConfiguration func(os *OrderService) error
type OrderService struct {
customers customer.CustomerRepository
}
// NewOrderService takes a variable amount of OrderConfiguration functions and returns a new OrderService
// Each OrderConfiguration will be called in the order they are passed in
func NewOrderService(cfgs ...OrderConfiguration) (*OrderService, error) {
os := &OrderService{}
// Apply all Configurations passed in
for _, cfg := range cfgs {
err := cfg(os)
if err != nil {
return nil, err
}
}
return os, nil
}
// WithCustomerRepository applies a given customer repository to the OrderService
func WithCustomerRepository(cr customer.CustomerRepository) OrderConfiguration {
// return a function that matches the OrderConfiguration alias,
// You need to return this so that the parent function can take in all the needed parameters
return func(os *OrderService) error {
os.customers = cr
return nil
}
}
// WithMemoryCustomerRepository applies a memory customer repository to the OrderService
func WithMemoryCustomerRepository() OrderConfiguration {
// Create the memory repo, if we needed parameters, such as connection strings they could be inputted here
cr := memory.New()
return WithCustomerRepository(cr)
}
Теперь можно добавлять методы к сервису, чтобы клиенты получили возможность покупать что-нибудь в таверне.
// CreateOrder will chain together all repositories to create a order for a customer
func (o *OrderService) CreateOrder(customerID uuid.UUID, productIDs []uuid.UUID) error {
// Get the customer
c, err := o.customers.Get(customerID)
if err != nil {
return err
}
// Get each Product, Ouchie, We need a ProductRepository
return nil
}
Упс, в нашей таверне нечего продавать. Но мы уже знаем, как это исправить: необходимо создать репозиторий для предлагаемых в таверне блюд и напитков.
ProductRepository: заключительный кусочек таверны
Теперь, когда мы знаем, для чего предназначен каждый компонент в DDD, настало время попрактиковаться. Для начала можно расширить ProductRepository, чтобы находить составляющие заказов. С этого момента будет чуть меньше объяснений, потому что мы уже рассмотрели основы.Создадим новый агрегат Product и фабрику для него.
// File: product.go
// Product is an aggregate that represents a product.
package aggregate
import (
"errors"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/entity"
)
var ErrMissingValues = errors.New("missing values")
// Product is a aggregate that combines item with a price and quantity
type Product struct {
// item is the root entity which is an item
item *entity.Item
price float64
// Quantity is the number of products in stock
quantity int
}
func NewProduct(name, description string, price float64) (Product, error) {
if name == "" || description == "" {
return Product{}, ErrMissingValues
}
return Product{
item: &entity.Item{
ID: uuid.New(),
Name: name,
Description: description,
},
price: price,
quantity: 0,
}, nil
}
func (p Product) GetID() uuid.UUID {
return p.item.ID
}
func (p Product) GetItem() *entity.Item {
return p.item
}
func (p Product) GetPrice() float64 {
return p.price
}
Обязательно добавим тесты, чтобы убедиться в правильности работы кода.
package aggregate_test
import (
"testing"
"github.com/percybolmer/ddd-go/aggregate"
)
func TestProduct_NewProduct(t *testing.T) {
type testCase struct {
test string
name string
description string
price float64
expectedErr error
}
testCases := []testCase{
{
test: "should return error if name is empty",
name: "",
expectedErr: aggregate.ErrMissingValues,
},
{
test: "validvalues",
name: "test",
description: "test",
price: 1.0,
expectedErr: nil,
},
}
for _, tc := range testCases {
t.Run(tc.test, func(t *testing.T) {
_, err := aggregate.NewProduct(tc.name, tc.description, tc.price)
if err != tc.expectedErr {
t.Errorf("Expected error: %v, got: %v", tc.expectedErr, err)
}
})
}
}
В файле domain/product/repository.go определим интерфейс ProductRepository, реализация которого обеспечит доступ к товарам.
// Package product holds the repository and the implementations for a ProductRepository
package product
import (
"errors"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
)
var (
ErrProductNotFound = errors.New("the product was not found")
ErrProductAlreadyExist = errors.New("the product already exists")
)
// ProductRepository is the repository interface to fulfill to use the product aggregate
type ProductRepository interface {
GetAll() ([]aggregate.Product, error)
GetByID(id uuid.UUID) (aggregate.Product, error)
Add(product aggregate.Product) error
Update(product aggregate.Product) error
Delete(id uuid.UUID) error
}
Как и в случае с репозиторием клиентов, реализуем хранилище в оперативной памяти: для этого в домене product создадим папку memory.
// Package memory is a in memory implementation of the ProductRepository interface.
package memory
import (
"sync"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"github.com/percybolmer/ddd-go/domain/product"
)
type MemoryProductRepository struct {
products map[uuid.UUID]aggregate.Product
sync.Mutex
}
// New is a factory function to generate a new repository of customers
func New() *MemoryProductRepository {
return &MemoryProductRepository{
products: make(map[uuid.UUID]aggregate.Product),
}
}
// GetAll returns all products as a slice
// Yes, it never returns an error, but
// A database implementation could return an error for instance
func (mpr *MemoryProductRepository) GetAll() ([]aggregate.Product, error) {
// Collect all Products from map
var products []aggregate.Product
for _, product := range mpr.products {
products = append(products, product)
}
return products, nil
}
// GetByID searches for a product based on it's ID
func (mpr *MemoryProductRepository) GetByID(id uuid.UUID) (aggregate.Product, error) {
if product, ok := mpr.products[uuid.UUID(id)]; ok {
return product, nil
}
return aggregate.Product{}, product.ErrProductNotFound
}
// Add will add a new product to the repository
func (mpr *MemoryProductRepository) Add(newprod aggregate.Product) error {
mpr.Lock()
defer mpr.Unlock()
if _, ok := mpr.products[newprod.GetID()]; ok {
return product.ErrProductAlreadyExist
}
mpr.products[newprod.GetID()] = newprod
return nil
}
// Update will change all values for a product based on it's ID
func (mpr *MemoryProductRepository) Update(upprod aggregate.Product) error {
mpr.Lock()
defer mpr.Unlock()
if _, ok := mpr.products[upprod.GetID()]; !ok {
return product.ErrProductNotFound
}
mpr.products[upprod.GetID()] = upprod
return nil
}
// Delete remove an product from the repository
func (mpr *MemoryProductRepository) Delete(id uuid.UUID) error {
mpr.Lock()
defer mpr.Unlock()
if _, ok := mpr.products[id]; !ok {
return product.ErrProductNotFound
}
delete(mpr.products, id)
return nil
}
Как всегда, добавим тесты.
package memory
import (
"testing"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"github.com/percybolmer/ddd-go/domain/product"
)
func TestMemoryProductRepository_Add(t *testing.T) {
repo := New()
product, err := aggregate.NewProduct("Beer", "Good for you're health", 1.99)
if err != nil {
t.Error(err)
}
repo.Add(product)
if len(repo.products) != 1 {
t.Errorf("Expected 1 product, got %d", len(repo.products))
}
}
func TestMemoryProductRepository_Get(t *testing.T) {
repo := New()
existingProd, err := aggregate.NewProduct("Beer", "Good for you're health", 1.99)
if err != nil {
t.Error(err)
}
repo.Add(existingProd)
if len(repo.products) != 1 {
t.Errorf("Expected 1 product, got %d", len(repo.products))
}
type testCase struct {
name string
id uuid.UUID
expectedErr error
}
testCases := []testCase{
{
name: "Get product by id",
id: existingProd.GetID(),
expectedErr: nil,
}, {
name: "Get non-existing product by id",
id: uuid.New(),
expectedErr: product.ErrProductNotFound,
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
_, err := repo.GetByID(tc.id)
if err != tc.expectedErr {
t.Errorf("Expected error %v, got %v", tc.expectedErr, err)
}
})
}
}
func TestMemoryProductRepository_Delete(t *testing.T) {
repo := New()
existingProd, err := aggregate.NewProduct("Beer", "Good for you're health", 1.99)
if err != nil {
t.Error(err)
}
repo.Add(existingProd)
if len(repo.products) != 1 {
t.Errorf("Expected 1 product, got %d", len(repo.products))
}
err = repo.Delete(existingProd.GetID())
if err != nil {
t.Error(err)
}
if len(repo.products) != 0 {
t.Errorf("Expected 0 products, got %d", len(repo.products))
}
}
Добавим OrderService-у возможность использовать ProductRepository с помощью соответствующей опции.
// OrderService is a implementation of the OrderService
type OrderService struct {
customers customer.CustomerRepository
products product.ProductRepository
}
// WithMemoryProductRepository adds a in memory product repo and adds all input products
func WithMemoryProductRepository(products []aggregate.Product) OrderConfiguration {
return func(os *OrderService) error {
// Create the memory repo, if we needed parameters, such as connection strings they could be inputted here
pr := prodmemory.New()
// Add Items to repo
for _, p := range products {
err := pr.Add(p)
if err != nil {
return err
}
}
os.products = pr
return nil
}
}
Давайте прокачаем метод CreateOrder: теперь можно искать заказанные продукты и возвращать суммарную их стоимость.
// CreateOrder will chain together all repositories to create a order for a customer
// will return the collected price of all Products
func (o *OrderService) CreateOrder(customerID uuid.UUID, productIDs []uuid.UUID) (float64, error) {
c, err := o.customers.Get(customerID)
if err != nil {
return 0, err
}
// Get each Product, Ouchie, We need a ProductRepository
var products []aggregate.Product
var price float64
for _, id := range productIDs {
p, err := o.products.GetByID(id)
if err != nil {
return 0, err
}
products = append(products, p)
price += p.GetPrice()
}
// All Products exists in store, now we can create the order
log.Printf("Customer: %s has ordered %d products", c.GetID(), len(products))
return price, nil
}
Поправим тесты order_test.go, чтобы сервис создавался с обоими репозиториями.
package services
import (
"testing"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
)
func init_products(t *testing.T) []aggregate.Product {
beer, err := aggregate.NewProduct("Beer", "Healthy Beverage", 1.99)
if err != nil {
t.Error(err)
}
peenuts, err := aggregate.NewProduct("Peenuts", "Healthy Snacks", 0.99)
if err != nil {
t.Error(err)
}
wine, err := aggregate.NewProduct("Wine", "Healthy Snacks", 0.99)
if err != nil {
t.Error(err)
}
products := []aggregate.Product{
beer, peenuts, wine,
}
return products
}
func TestOrder_NewOrderService(t *testing.T) {
// Create a few products to insert into in memory repo
products := init_products(t)
os, err := NewOrderService(
WithMemoryCustomerRepository(),
WithMemoryProductRepository(products),
)
if err != nil {
t.Error(err)
}
// Add Customer
cust, err := aggregate.NewCustomer("Percy")
if err != nil {
t.Error(err)
}
err = os.customers.Add(cust)
if err != nil {
t.Error(err)
}
// Perform Order for one beer
order := []uuid.UUID{
products[0].GetID(),
}
_, err = os.CreateOrder(cust.GetID(), order)
if err != nil {
t.Error(err)
}
}
Tavern: сервис, который содержит другие сервисы
Приступаем к заключительной части: сервису Tavern. У него будет доступ к OrderService, чтобы создавать заказы. Такая упаковка помогает реализовать дополнительную логику. Например, для Tavern целесообразно управлять счетами. Обратите внимание, как легко мы можем встроить логику заказов в этот сервис, не заботясь о подробностях реализации.package services
import (
"log"
"github.com/google/uuid"
)
// TavernConfiguration is an alias that takes a pointer and modifies the Tavern
type TavernConfiguration func(os *Tavern) error
type Tavern struct {
// orderservice is used to handle orders
OrderService *OrderService
// BillingService is used to handle billing
// This is up to you to implement
BillingService interface{}
}
// NewTavern takes a variable amount of TavernConfigurations and builds a Tavern
func NewTavern(cfgs ...TavernConfiguration) (*Tavern, error) {
// Create the Tavern
t := &Tavern{}
// Apply all Configurations passed in
for _, cfg := range cfgs {
// Pass the service into the configuration function
err := cfg(t)
if err != nil {
return nil, err
}
}
return t, nil
}
// WithOrderService applies a given OrderService to the Tavern
func WithOrderService(os *OrderService) TavernConfiguration {
// return a function that matches the TavernConfiguration signature
return func(t *Tavern) error {
t.OrderService = os
return nil
}
}
// Order performs an order for a customer
func (t *Tavern) Order(customer uuid.UUID, products []uuid.UUID) error {
price, err := t.OrderService.CreateOrder(customer, products)
if err != nil {
return err
}
log.Printf("Bill the Customer: %0.0f", price)
// Bill the customer
// err = t.BillingService.Bill(customer, price)
return nil
}
Чтобы попробовать сервис в деле, можно создать тест.
package services
import (
"testing"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
)
func Test_Tavern(t *testing.T) {
// Create OrderService
products := init_products(t)
os, err := NewOrderService(
WithMemoryCustomerRepository(),
WithMemoryProductRepository(products),
)
if err != nil {
t.Error(err)
}
tavern, err := NewTavern(WithOrderService(os))
if err != nil {
t.Error(err)
}
cust, err := aggregate.NewCustomer("Percy")
if err != nil {
t.Error(err)
}
err = os.customers.Add(cust)
if err != nil {
t.Error(err)
}
order := []uuid.UUID{
products[0].GetID(),
}
// Execute Order
err = tavern.Order(cust.GetID(), order)
if err != nil {
t.Error(err)
}
}
Давайте теперь заменим реализацию CustomerRepository. Выберем в качестве реального хранилища MongoDB. Тут паттерн «репозиторий» засияет во всей красе. Я очень ценю возможность заменить с такой лёгкостью репозиторий.
Создадим пакет mongo внутри домена customer и структуру, удовлетворяющую репозиторию CustomerRepository.
Хочется отметить внутреннюю структуру mongoCustomer, которая используется непосредственно для управления данными из MongoDB. Мы не стали использовать для этих целей уже готовый aggregate.Customer, потому что это связало бы агрегат и хранилище (в агрегат просочились бы bson-теги и заменить при желании хранилище стало бы сложно). А мы, наоборот, хотим, чтобы репозиторий полностью отвечал за (де)сериализацию данных, не распространяя свои внутренние сущности вовне. Поэтому мы и не использовали непосредственно в структуре агрегата теги json или bson. Перегонять же из внутренней структуры в агрегат и наоборот будем с помощью функций.
// Mongo is a mongo implementation of the Customer Repository
package mongo
import (
"context"
"time"
"github.com/google/uuid"
"github.com/percybolmer/ddd-go/aggregate"
"go.mongodb.org/mongo-driver/bson"
"go.mongodb.org/mongo-driver/mongo"
"go.mongodb.org/mongo-driver/mongo/options"
)
type MongoRepository struct {
db *mongo.Database
// customer is used to store customers
customer *mongo.Collection
}
// mongoCustomer is an internal type that is used to store a CustomerAggregate
// we make an internal struct for this to avoid coupling this mongo implementation to the customeraggregate.
// Mongo uses bson so we add tags for that
type mongoCustomer struct {
ID uuid.UUID `bson:"id"`
Name string `bson:"name"`
}
// NewFromCustomer takes in a aggregate and converts into internal structure
func NewFromCustomer(c aggregate.Customer) mongoCustomer {
return mongoCustomer{
ID: c.GetID(),
Name: c.GetName(),
}
}
// ToAggregate converts into a aggregate.Customer
// this could validate all values present etc
func (m mongoCustomer) ToAggregate() aggregate.Customer {
c := aggregate.Customer{}
c.SetID(m.ID)
c.SetName(m.Name)
return c
}
// Create a new mongodb repository
func New(ctx context.Context, connectionString string) (*MongoRepository, error) {
client, err := mongo.Connect(ctx, options.Client().ApplyURI(connectionString))
if err != nil {
return nil, err
}
// Find Metabot DB
db := client.Database("ddd")
customers := db.Collection("customers")
return &MongoRepository{
db: db,
customer: customers,
}, nil
}
func (mr *MongoRepository) Get(id uuid.UUID) (aggregate.Customer, error) {
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
result := mr.customer.FindOne(ctx, bson.M{"id": id})
var c mongoCustomer
err := result.Decode(&c)
if err != nil {
return aggregate.Customer{}, err
}
// Convert to aggregate
return c.ToAggregate(), nil
}
func (mr *MongoRepository) Add(c aggregate.Customer) error {
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
internal := NewFromCustomer(c)
_, err := mr.customer.InsertOne(ctx, internal)
if err != nil {
return err
}
return nil
}
func (mr *MongoRepository) Update(c aggregate.Customer) error {
panic("to implement")
}
Далее нужно добавить функцию-конфигуратор для внедрения нового репозитория в OrderService.
func WithMongoCustomerRepository(connectionString string) OrderConfiguration {
return func(os *OrderService) error {
// Create the mongo repo, if we needed parameters, such as connection strings they could be inputted here
cr, err := mongo.New(context.Background(), connectionString)
if err != nil {
return err
}
os.customers = cr
return nil
}
}
Теперь можно с лёгкостью заменить один репозиторий на другой.
func Test_MongoTavern(t *testing.T) {
// Create OrderService
products := init_products(t)
os, err := NewOrderService(
WithMongoCustomerRepository("mongodb://localhost:27017"),
WithMemoryProductRepository(products),
)
if err != nil {
t.Error(err)
}
tavern, err := NewTavern(WithOrderService(os))
if err != nil {
t.Error(err)
}
cust, err := aggregate.NewCustomer("Percy")
if err != nil {
t.Error(err)
}
err = os.customers.Add(cust)
if err != nil {
t.Error(err)
}
order := []uuid.UUID{
products[0].GetID(),
}
// Execute Order
err = tavern.Order(cust.GetID(), order)
if err != nil {
t.Error(err)
}
}
Теперь наша таверна умеет работать как с in-memory хранилищем, так и с MongoDB.
Вот мы и познакомились с основами предметно-ориентированного проектирования. Основные термины, с которыми мы поработали:
- сущности (entities) — изменяемые структуры с идентификатором;
- объекты-значения (value objects) — неизменяемые структуры без идентификаторов;
- агрегаты (aggregates) — комбинация сущностей и объектов-значений под управлением репозиториев;
- репозиторий (repository) — реализация управления агрегатами;
- фабрика (factory) — конструктор для создания сложных объектов и упрощения получения их экземпляров в соседних доменах;
- сервис (service) — набор репозиториев и, возможно, других сервисов, которые вместе формируют бизнес-логику приложения.
Рефакторинг
Переносим агрегаты в соответствующие доменные пакеты
Первым делом избавимся от пакета aggregate. Мы уже разобрались, для чего нужны агрегаты, так что теперь нет необходимости так называть пакет. Я склоняюсь к тому, что агрегаты следует помещать в соответствующий домен. Например, агрегат Customer окажется в пакете-домене customer.
Переносим объекты-значения и сущности
У нас ещё есть папки entity и valueobject, что, я думаю, не так уж и плохо, ведь хранение разделяемых структур в отдельных пакетах позволяет избежать циклических импортов. Однако того же эффекта можно добиться иным, более изящным способом. Заведем корневой пакет tavern и переместим туда все сущности и объекты-значения. Получим следующую структуру проекта:
Не забудьте, что в этом случае придётся заново выполнить go mod init и переименовать импорты.
Разделение пакета с сервисами
Сейчас все сервисы находятся в одном пакете. Я предпочту разделить его на два: order и tavern. При развитии проекта это предотвратит замусоривание пакета с сервисами. Ещё одним аргументом в пользу такого решения послужит будущее усложнение проекта: запросто может появиться сервис обработки заказов не от индивидуальных клиентов, а от компаний.
Наконец, перед нами итоговый вид проекта.
Заключительный совет, который я хочу вам дать: держите в проекте папку cmd с пакетами запуска приложений внутри проекта. Это может быть запуск API, consumer-а, однократных скриптов и миграций. В папке cmd следует сосредоточить использование инструментов для запуска приложения из командной строки и разнообразные настройки при инициализации.
Как реализовать DDD в Go
Image by Percy Bolmér. Gopher by Takuya Ueda, Original Go Gopher by Renée French (CC BY 3.0) С помощью микросервисной архитектуры можно построить масштабируемое и гибкое приложение. Однако, если...
habr.com