orders

README

This folder contains the domain logic for the orders module.

Following hexagonal architecture, the domain logic is separated from any external code via interfaces. Domain code and ports exist in the root of this folder, and has no external dependencies Both driving and driven adapters are implemented in the "adapters" folder.

Examples

For example, order_service.go defines the functions exposed by the order module in an interface called OrderService (the driving port).

This interface is implemented in the file adapters/gin_order_service.go, which maps the individual OrderService functions to HTTP endpoints using the gin framework. You could imagine other driving adapters for OrderService using other HTTP frameworks, or another protocol like GRPC or RabbitMQ.

Similarly, for the driven adapter, order_repo.go defines an interface OrderRepo for entity persistence. This interface can be implemented using various technologies: an in-memory map (./adapters/in_memory_order_repo.go), a postgres database, or any other storage mechanism.

Composition

Because every module only relies on interfaces, we need somewhere in code where instances are instantiated and supplied. This all happens in our composition root, cmd/app/main.go. As the application gets sufficiently complex, we may end up using a Dependency-Injection framework to help this along, but for now manual dependency injection is fine.

Documentation

Index

• type Order
• type OrderRepository
• type OrderService
• type OrderServiceImpl
  • func NewOrderService(repo OrderRepository) *OrderServiceImpl
  • func (os *OrderServiceImpl) CreateOrder(product string, quantity int) (*Order, error)
  • func (os *OrderServiceImpl) GetOrder(id string) (*Order, error)
  • func (os *OrderServiceImpl) GetOrders() ([]Order, error)
• type OrderStatus

Types

type Order

type Order struct {
	ID       string
	Product  string
	Quantity int
	Status   OrderStatus
}

Order is a pure domain object, representing an order managed by our application.

NOTE: this struct has no relationships with any specific storage mechism or database. Each implementation of OrderRepository will have to convert from this struct to data-types appropriate for the storage mechanism.

type OrderRepository

type OrderRepository interface {
	Save(order *Order) error

	GetMany() ([]Order, error)

	GetOne(id string) (*Order, error)
}

Output port - defines function calls this module makes to external services in this case, calls related to order storage and persistence

type OrderService

type OrderService interface {
	CreateOrder(product string, quantity int) (*Order, error)
	GetOrders() ([]Order, error)
	GetOrder(id string) (*Order, error)
}

Input / driving port - defines the functions exposed by this application to external components Driving adapters should implement this interface to expose this application using a specific protocol

Example - an HTTP adapter would create HTTP endpoints for each function
Example - a GRPC adapter would expose a GRPC service with unary RPCs for each function

type OrderServiceImpl

type OrderServiceImpl struct {
	// contains filtered or unexported fields
}

This struct implements OrderService using ports for all external component interaction.

Ideally, what is left is pure business logic which is both easily testable, and agnostic of any intrastructure changes made during the lifespan of this project.

func NewOrderService

func NewOrderService(repo OrderRepository) *OrderServiceImpl

func (*OrderServiceImpl) CreateOrder

func (os *OrderServiceImpl) CreateOrder(product string, quantity int) (*Order, error)

func (*OrderServiceImpl) GetOrder

func (os *OrderServiceImpl) GetOrder(id string) (*Order, error)

func (*OrderServiceImpl) GetOrders

func (os *OrderServiceImpl) GetOrders() ([]Order, error)

type OrderStatus

type OrderStatus string

const (
	RECEIVED  OrderStatus = "RECEIVED"
	SHIPPED   OrderStatus = "SHIPPED"
	DELIVERED OrderStatus = "DELIVERED"
)