Digest | DDD概述, SOLID: 接口隔离原则, Learning by Doing

> 2021年11月26信息消化

### DDD in a nutshell

origin: [DDD in a nutshell](https://tech.tamara.co/ddd-in-a-nutshell-3852b0a6155a)

> Domain-driven design is the concept that the structure and language of **software code should match the business domain**. For example, if a software processes loan applications, it might have classes such as LoanApplication and Customer, and methods such as AcceptOffer and Withdraw. [Wikipedia](https://en.wikipedia.org/wiki/Domain-driven_design)

In general, talking upon DDD mainly about Strategic and Tactical patterns:

- **The strategic pattern** will help you design your domains, sub-domains that are communicated by the ubiquitous language then support you to organize/structure your teams based on that outcome.
- **The tactical pattern** will guide you on how to implement your application in a scaling way.

#### Strategic Design

> Strategic pattern helps you design your domains, sub-domains that are communicated by the **ubiquitous language** then support you to organize/structure your teams based on that outcome.

![img](https://raw.githubusercontent.com/Phalacrocorax/memo-image-host/master/uPic/1*vLC-bTHsWR8Vmfo_VR_HTQ.jpeg)

#### Tactical Design

>  Tactical pattern will guide you on how to implement your application in a scaling way.

![img](https://raw.githubusercontent.com/Phalacrocorax/memo-image-host/master/uPic/1*iWJ0ihKzNGpjaDbWqFWPDg.png)

The Tactical Design helps you create an elegant Domain Model using Building Blocks, see below the main Building Blocks:

##### Aggregates

It is one of the most important and complex patterns of *Tactical Design*, *Aggregates* are based on two other *Tactical Standards*, which are *Entities* and *Value Objects*. An *Aggregate* is a Cluster of one or more *Entities*, and may also contain *Value Objects*. The Parent *Entity* of this Cluster receives the name of *Aggregate Root*. (*thedomaindrivendesign.io*)

For instance, in the Ecommerce domain, you will have Order as an aggregate which contains Address (Value Object) and Consumer (Entity)

它是战术设计中最重要和最复杂的模式之一，聚合基于另外两个战术标准，即实体和值对象。聚合是一个或多个实体的集群，也可能包含值对象。该集群的父实体接收聚合根的名称。 （域驱动设计.io） 例如，在电子商务领域，您将订单作为包含地址（值对象）和消费者（实体）的聚合体

##### Entities

An *Entity* is a potentially changeable object, which has a unique identifier. *Entities* have a life of their own within their *Domain Model*, which enables you to obtain the entire transition history of this *Entity.*

实体是一个潜在的可变对象，它有一个唯一的标识符。实体在它们的领域模型中有自己的生命周期，这使您能够获得该实体的整个转换历史。

##### Value Objects

What differentiates a *Value Object* from an *Entity* is that *Value Objects* are **immutable** and do not have a unique identity, are defined only by the values of their attributes. The consequence of this immutability is that in order to update a *Value Object*, you must create a new instance to replace the old one.
值对象与实体的区别在于值对象是不可变的并且没有唯一标识，仅由其属性值定义。这种不变性的结果是，为了更新值对象，您必须创建一个新实例来替换旧实例。

##### Services

*Services* are **stateless objects** that perform some logic that do not fit with an operation on an *Entity* or *Value Object*.
They perform domain-specific operations, which can involve multiple domain objects.

服务是无状态对象，它们执行一些不适合对实体或值对象的操作的逻辑。 它们执行特定于域的操作，这可能涉及多个域对象。

##### Repositories

*Repositories* are mainly used to deal with storage, they abstract concerns about data storage. They are responsible for persisting *Aggregates*.

存储库主要用于处理存储，它们抽象了对数据存储的关注。他们负责持久化聚合。

##### Factories

*Factories* are used to provide abstraction in the construction of an Object and can return an *Aggregate* root, an *Entity*, or a *Value Object*. *Factories* are an alternative for building objects that have complexity in building via the constructor method.

工厂用于在对象的构造中提供抽象，并且可以返回聚合根、实体或值对象。工厂是通过构造函数方法构建具有复杂性的对象的替代方法。

##### Events

*Events* indicate significant occurrences that have occurred in the domain and need to be reported to other stakeholders belonging to the domain. It is common for *Aggregates* to publish events.

事件表示领域中发生的重大事件，需要向属于该领域的其他利益相关者报告。聚合发布事件是很常见的。

##### Modules

*Modules* are little mentioned by the developers, however, their use can be very interesting.
Modules help us segregate concepts, can be defined as a *package* or a *namespace* depending on the programming languages, and always follow the *Ubiquitous Language*.

*(The building blocks text is from thedomaindrivendesign.io)*

Combining the above building blocks, the Tactical Design also comes with many valuable patterns such as **CQRS — Event Sourcing,** **Layered Architecture**… which will help you build better software that is easy to maintain and extend.

结合上述构建块，Tactical Design 还附带了许多有价值的模式，例如 **CQRS** — 事件溯源、分层架构……这将帮助您构建更好的易于维护和扩展的软件。

In the upcoming articles, we will discuss more details about that patterns.

At Tamara, we are applying the DDD approach from the beginning, and it helps us a lot in building an excellent service that serves both Merchants and Consumers daily.

### Practical SOLID in Golang: Interface Segregation Principle

origin: [Practical SOLID in Golang: Interface Segregation Principle](https://levelup.gitconnected.com/practical-solid-in-golang-interface-segregation-principle-f272c2a9a270)

> MEMO 接口隔离原则
> 按context去区分接口。比如登录用户和未登录用户区别很大，做接口区分（不需要isLoggedIn方法），在登录用户里实现普通用户和高级用户。
> Whenever we want to **cover more types**, we should **protect them with different interfaces**. We should avoid making our interfaces too small but deliver complete functionality.

#### When we do not respect The Interface Segregation

> Keep interfaces small so that users don’t end up depending on things they don’t need.

[Uncle Bob](https://twitter.com/unclebobmartin) coined this principle, and more details about it you can find on his [blog](https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html). This principle clearly defines its requirement, probably the best of all other SOLID principles.

Its simple statement to keep interfaces as small as possible we should not understand as just one-method-interface, but to look more in a context of the **features’ cohesion** that interface holds.

Let us examine the code below:

```go
type User interface {
	AddToShoppingCart(product Product)
	IsLoggedIn() bool
	Pay(money Money) error
	HasPremium() bool
	HasDiscountFor(product Product) bool
	//
	// some additional methods
	//
}

type Guest struct {
	cart ShoppingCart
	//
	// some additional fields
	//
}

func (g *Guest) AddToShoppingCart(product Product) {
	g.cart.Add(product)
}

func (g *Guest) IsLoggedIn() bool {
	return false
}

func (g *Guest) Pay(Money) error {
	return errors.New("user is not logged in")
}

func (g *Guest) HasPremium() bool {
	return false
}

func (g *Guest) HasDiscountFor(Product) bool {
	return false
}

type NormalCustomer struct {
	cart   ShoppingCart
	wallet Wallet
	//
	// some additional fields
	//
}

func (c *NormalCustomer) AddToShoppingCart(product Product) {
	c.cart.Add(product)
}

func (c *NormalCustomer) IsLoggedIn() bool {
	return true
}

func (c *NormalCustomer) Pay(money Money) error {
	return c.wallet.Deduct(money)
}

func (c *NormalCustomer) HasPremium() bool {
	return false
}

func (c *NormalCustomer) HasDiscountFor(Product) bool {
	return false
}

type PremiumCustomer struct {
	cart     ShoppingCart
	wallet   Wallet
	policies []DiscountPolicy
	//
	// some additional fields
	//
}

func (c *PremiumCustomer) AddToShoppingCart(product Product) {
	c.cart.Add(product)
}

func (c *PremiumCustomer) IsLoggedIn() bool {
	return true
}

func (c *PremiumCustomer) Pay(money Money) error {
	return c.wallet.Deduct(money)
}

func (c *PremiumCustomer) HasPremium() bool {
	return true
}

func (c *PremiumCustomer) HasDiscountFor(product Product) bool {
	for _, p := range c.policies {
		if p.IsApplicableFor(c, product) {
			return true
		}
	}
	
	return false
}

type UserService struct {
	//
	// some fields
	//
}

func (u *UserService) Checkout(ctx context.Context, user User, product Product) error {
	if !user.IsLoggedIn() {
		return errors.New("user is not logged in")	
	}
	
	var money Money
	//
	// some calculation
	//
	if user.HasDiscountFor(product) {
		//
		// apply discount
		//
	}
	
	return user.Pay(money)
}
```

Let us assume we want to deliver an application for shopping. One of the approaches is to define an interface `User`, as we did in the code example. This interface holds many features a user can have.

A `User` on our platform can add a `Product` to the `ShoppingCart`. They can buy it. They can get a discount on a particular `Product`. The only problem is that only a specific `User` can do all of that.

The actual implementations for this interface are three structs. The first one is the `Guest` struct. It should be a `User` who is not logged in on our system, but at least they can add a `Product` to the `ShoppingCart`.

The second implementation is the `NormalCustomer`. It can do whatever `Guest` can, plus to buy a `Product`. The third implementation is the`PremiumCustomer`, which can use all features of our system.

Now, look at all of those three structs. Only `PremiumCustomer` requires all three methods. Maybe we can assign all of them to `NormalCustomer`, but definitely, we hardly need more than two for `Guest`.

Methods `HasPremium` and `HasDiscountFor` do not have any sense for `Guest`. If that struct represents the `User` who is not logged in, why would we even consider implementing methods for discounts?

And we did all of this to add generalization inside UserService to handle all types of `Users` in the same place, with the same code. But, because of that, we need to implement a bunch of unused methods.

So, to have better generalization, we got:

1. Many structs with unused methods.
2. Methods that we need somehow to mark so that others do not use them.
3. Much additional code for unit testing.
4. Unnatural polymorphism.
5. …

So, let us refactor this mess.

##### How we do respect The Interface Segregation

> Build interfaces around the minimal cohesive group of features.

We do not need to invent some space science here. The only needed is to define a minimal interface that delivers a complete set of features. Let us check the code below:

```go
type User interface {
	AddToShoppingCart(product Product)
	//
	// some additional methods
	//
}

type LoggedInUser interface {
	User
	Pay(money Money) error
	//
	// some additional methods
	//
}

type PremiumUser interface {
	LoggedInUser
	HasDiscountFor(product Product) bool
	//
	// some additional methods
	//
}