6 of 59

eCommerce application from past 15 years

Traditional monolithic design - Introduction to cloud-native applications | Microsoft Learn

You construct a large core application containing all of your domain logic. It includes modules such as Identity, Catalog, Ordering, and more. They directly communicate with each other within a single server process. The modules share a large relational database. The core exposes functionality via an HTML interface and a mobile app.

Congratulations! You just created a monolithic application.

Not all is bad. Monoliths offer some distinct advantages. For example, they're straightforward to...

build
test
deploy
troubleshoot
vertically scale

Many successful apps that exist today were created as monoliths. The app is a hit and continues to evolve, iteration after iteration, adding more functionality.

At some point, however, you begin to feel uncomfortable. You find yourself losing control of the application. As time goes on, the feeling becomes more intense, and you eventually enter a state known as the Fear Cycle:

The app has become so overwhelmingly complicated that no single person understands it.
You fear making changes - each change has unintended and costly side effects.
New features/fixes become tricky, time-consuming, and expensive to implement.
Each release becomes as small as possible and requires a full deployment of the entire application.
One unstable component can crash the entire system.
New technologies and frameworks aren't an option.
It's difficult to implement agile delivery methodologies.
Architectural erosion sets in as the code base deteriorates with never-ending "quick fixes."
Finally, the consultants come in and tell you to rewrite it.

7 of 59

Native

= พื้นเมือง

Cloud Native

= “คลาวไทยบ้าน”

= ไทยบ้าน ในภาษาอีสาน

8 of 59

Cloud Native

ช่วยให้องค์พัฒนาระบบที่มีความสามารถในการรองรับปริมาณการใช้งานจากลูกค้าจำนวนมากได้เพราะมีความยืดหยุ่นในการดูแลรักษา เช่น

สามารถที่จะขยายระบบให้เพียงพอกับลูกค้าในแต่ละช่วงเวลา (Scalable)
รองรับการดูแล Infrastructure ทั้งแบบ On-premise หรือการทำงานร่วมกับ Cloud Deployment Model ทั้งแบบ Public/Private/Hybrid Cloud
ระบบแต่ละส่วนมีความยืดหยุ่นจากกัน
รองรับการพัฒนาด้วยเทคโนโลยีที่หลากหลายมากขึ้น
ลดเวลาในการติดตั้งระบบลง

9 of 59

eCommerce application adopting a cloud-native approach

Introduction to cloud-native applications | Microsoft Learn

10 of 59

medium.com/@victorcodes/backing-services

“ There was a lot of techniques/configuration ”

11 of 59

aka.ms/dotnet-aspire

github.com/dotnet/aspire

“ Provide minimal components for resiliency defaults, health checks, telemetry, and integrate with DI ”

12 of 59

Install .NET Aspire

To work with .NET Aspire, you'll need the following installed locally:

.NET 8.0
.NET Aspire workload
Docker Desktop
Integrated Developer Environment (IDE) or code editor, such as:

Visual Studio 2022 Preview version 17.9 or higher (Optional)
Visual Studio Code (Optional)

18 of 59

.NET Aspire Component

Components are glue libraries that configure an SDK to operate in a cloud environment

Leverage configurable resilience patterns such as retries, timeouts, and circuit breakers to maximize availability.
Expose health checks enabling applications to track and respond to the remote service’s health.
Offer integrated logging, metrics, and tracing using modern .NET abstractions (ILogger, Meter, Activity).
Offer extension methods that ‘glue’ the services from the SDK to the DI container with the right lifetime for the types being registered.

19 of 59

dotnet add package Aspire.RabbitMQ.Client --prerelease

+Host Project: var rabbit = builder.AddRabbitMQContainer("rabbit");

+ServiceDefaults Project

Aspire.RabbitMQ.Client

Common service-centric logic

that applies across all the projects

Microsoft.Extensions.ServiceDiscovery

Healthcheck

Logging

20 of 59

.NET Aspire References

21 of 59

เห็นคำว่า Clean แล้วนึกถึงอะไร

23 of 59

Robert C. Martin (Uncle Bob)

24 of 59

Clean Code

“เน้นไปที่รายละเอียดของโค้ด

ที่ทำความเข้าใจง่าย ดูแลรักษาง่าย”

Clean Architecture

“เน้นไปที่การออกแบบระบบโดยรวม

ที่เน้นความยืดหยุ่น รองรับการเปลี่ยนแปลง ทดสอบง่าย”

“ทั้งสองล้วนจำเป็นในการสร้างซอฟต์แวร์คุณภาพและบำรุงรักษาได้ดีในระยะยาว”

25 of 59

Clean Code

Clean Code - Saladpuk.com

26 of 59

Clean Code - Saladpuk.com

27 of 59

Clean Code - Saladpuk.com

28 of 59

Traditional "N-Layer" architecture applications

docs.microsoft.com

29 of 59

มันก็ทำงานได้นะ แล้วทำไมเราต้องมี �Clean Architecture

30 of 59

พี่ขอเปลี่ยนฐานข้อมูล

จาก MySQL

เป็น MSSQL

น่าจะใช้เวลาแก้ไม่นาน

ใช่ไหมครับ

ลูกค้า

ผู้น่าร้ากกก

Developer ท่านนึง

31 of 59

Clean Architecture with ASP.NET Core 8 | .NET Conf 2023

32 of 59

“Dividing the software into layers for separation of concerns”

Independent of Frameworks
Testable
Independent of UI
Independent of Database
Independent of any external agency

Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.

Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.

Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.

Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.

Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.

33 of 59

Clean Architecture - Uncle Bob

Clean Coder Blog

The Dependency Rule ของ Clean Architecture

จากภาพข้างบน เราจะเห็นได้ว่า แต่ละวงกลมจะสื่อถึง layer ต่างๆ เวลาที่เราทำ software ใดๆ ก็ตาม โดยวงกลมที่อยู่ด้านนอกๆ จะสื่อถึง layer ที่สูงๆ ซึ่งโดยทั่วไปก็จะเป็นส่วนที่ติดต่อกับคนที่ใช้งาน ส่วนวงกลมที่อยู่ด้านในๆ ก็จะเป็นส่วนที่ low level มากๆ อย่างเช่น ส่วนที่ติดต่อกับ database เป็นต้น�.�เรามาทำความรู้จักมากขึ้นกับวงกลมแต่ละ layer ให้มากขึ้นกันดีกว่า 🎉

Entities

ส่วนนี้เป็นส่วนที่ติดต่อกับ Enterprise Business Rules ซึ่งโค้ดที่เกิดขึ้นใน layer นี้ อาจจะเป็น model ที่เก็บ data structure ของข้อมูลในองค์กรของเราก็ได้ โดยส่วนนี้จะมีการเปลี่ยนแปลง และกระทบน้อยที่สุด เนื่องจากเป็นชั้นด้านในที่สุดเลย เช่น ถ้าหากเราเปลี่ยนแปลง UI จาก design แบบหนึ่ง ไปเป็นอีกแบบหนึ่ง ก็จะมีโอกาสน้อยมากที่ structure ของ data ของเราจะเปลี่ยนแปลงไปตาม

Use Cases

ส่วนนี้จะเป็นส่วนที่มี Application Business Rules อยู่ ซึ่งโค้ดใน use case เหล่านี้ก็จะเป็นส่วนที่ควบคุมว่าจะมี data อะไรที่จะนำออกจาก.. หรือนำเข้าไป entities บ้าง โดยที่จะทำให้ได้ผลลัพธ์อย่างที่โปรแกรมของเราต้องการ

Interface Adapters

ส่วนนี้จะประกอบไปด้วยส่วนที่เอาไว้ใช้ convert data จาก format ใดๆ ก็ตาม ให้เป็น format ที่ application ของเราเข้าใจและใช้ได้ง่าย เช่นการแปลงจาก json format ให้เป็น object ที่เราต้องการ เราจะเรียกสิ่งที่ทำหน้าที่เหล่านี้ว่า Adapter ซึ่ง Adapter ถ้าแปลเป็นไทยก็คือ "ตัวแปลง" นั่นเอง

Frameworks and Drivers

เป็นส่วนที่จัดการกับ framework ที่เราใช้ในโปรเจกต์ ในส่วนนี้เราอาจจะไม่ได้เขียนโค้ดมาก แต่ก็เป็นส่วนที่สำคัญ เพราะเราเอาไว้ใช้ ติดต่อกับ framework ต่างๆ ที่เราใช้ เช่น การเขียนโค้ดเพื่อสร้าง database connection เป็นต้น

34 of 59

Clean Architecture with ASP.NET Core 8 | .NET Conf 2023

35 of 59

Clean Architecture with ASP.NET Core 8 | .NET Conf 2023

36 of 59

Clean Architecture with ASP.NET Core 8 | .NET Conf 2023

37 of 59

ยังไม่เสร็จ T_T

39 of 59

อธิบายโครงสร้างของ Source Code

Domain: ดูแลในเรื่องของ Entity สำหรับการสร้างฐานข้อมูลครับ จะถูกนำไปใช้ที่ Project Core ในการพัฒนา Business Logic และใน Project Infra ในตอนที่สร้าง Entity Framework Database Context
Core: เป็น Main Business Logic หลักของระบบครับผม จะมีการกำหนด Interface ในส่วนของ Infra ไว้สำหรับการเชื่อมต่อ Backing Service ภายนอกเช่น Database/Email และจะนำ Interface เหล่านี้มาใช้มีการ Implement ในส่วนของ Business Service Logic ด้วยครับ
Infra: ดูแลในเรื่องของการนำ Interface จาก Core มา Implement เพื่อให้ระบบสามารถเชื่อมต่อกับ 3rd Parties Services ต่างๆได้ เช่น Database Server, Email Server, SMS Gateway
API: เป็นช่องทางสำหรับให้ Client มาเชื่อมต่อเพื่อใช้บริการแลกเปลี่ยนข้อมูลในระบบเรา

ในการติดต่อกันจะทำผ่าน Contract นะครับ หรือก็คือ Interface ของเรา ไม่ได้มีการเรียกถึงกันตรงๆ เพื่อความยืดหยุ่นในการดูแลรักษาระบบครับผม — Loose Coupling

40 of 59

Dependency Non-Injection

“New is Glue.”

ก่อนอื่นเรามาทำความรู้จักกับ Dependency Non-Injection กันก่อนนะครับ ก็คือการที่ Class นึงมีการเรียกใช้อีก Class นึง

ซึ่งเราจะต้องใช้คำสั่ง New เพื่อที่จะสร้าง Object ของอีก Class มาใช้งาน ตรงนี้ละที่เราเรียกว่า Dependency เพราะมีการพึ่งพา Class อื่นเกิดขึ้น

ทีนี้การใช้คำสั่ง New ทำให้โครงสร้างของโปรแกรมเราไม่ยืดหยุ่น ปรับแต่งต่อยากครับ เพราะ Class แต่ละ Class สัมพันธ์กันแบบแน่นแยกออกจากกันลำบาก (High Coupling)

ในตัวอย่างข้างบนจะพบว่า NewClass นั้นผูกติดกับ EmailService แน่นเลย เพราะไปสั่ง New ที่ Constructor ถ้าเราอยากจะเปลี่ยนเป็น Class อื่นก็จะกระทบ NewClass อีก

41 of 59

Interface

Interface เป็นส่วนที่สำคัญมากๆที่ผมอยากให้ผู้อ่านได้ศึกษาและทำความเข้าใจก่อนที่จะเริ่มใช้ .NET 6 ครับ เพราะมีส่วนสำคัญที่ช่วยให้ Code ของเราไม่ผูกพันกันแน่นไป ยืดหยุ่น รองรับการเปลี่ยนแปลง และสามารถทดสอบได้ง่ายครับ

โดย Interface เป็นมาตราฐาน/สัญญาที่เรากำหนดขึ้นมาให้กับ Class ที่จะนำ Interface ไป Implement นั้นปฎิบัติตามเพื่อให้มีโครงสร้างตามที่ Interface กำหนดเช่นเรื่องของชื่อ Function, Input, Output ที่จะเกิดขึ้น

ตัวอย่างเช่น Interface ของ Mobile Phone คือการกำหนดว่าต้องสามารถโทรออกได้ด้วยการระบุเบอร์โทรศัพท์ปลายทาง และส่งข้อความได้ด้วยการระบุเบอร์โทรศัพท์ปลายทางนะ

แต่ขั้นตอนในการทำงานนั้นก็แล้วแต่ค่ายผู้ผลิตมือถือเลยครับ ซึ่งเป็นข้อดีมากๆเพราะมีมาตราฐานกลางในการสื่อสารกัน ทำให้ทั้งผู้ให้บริการ(ค่ายมือถือ) สามารถพัฒนา Features ต่างๆได้อย่างอิสระ และ ผู้ใช้บริการ (คนซื้อมือถือ) ก็ไม่ต้องเรียนรู้การใช้งานเพิ่มเติม เพราะยังคงอยู่บนพื้นฐานของมาตราฐานเดียวกันกับมือถือเจ้าอื่นที่เคยใช้

42 of 59

Dependency Inversion Principle:คือ Software Design Principle ที่แนะนำชี้ให้เห็นถึงปัญหาเกี่ยวกับเรื่องของ Dependency แต่ไม่ได้บอกว่าใช้เทคนิคอะไรในการแก้ไขปัญหา
Inversion of Control (IoC): คือการนำ Dependency Inversion Principle มากำหนดแนวทางการพัฒนาให้ Components อ้างอิงกับ Abstraction แทนการอ้างอิงกับ Concrete Implementation.
Dependency Injection (DI): คือ Design Patternในการนำ IoC มาพัฒนา โดยจะทำการ Inject Concrete Implementation ระหว่าง Components
IoC Container (DI Container): คือ Programming Framework ที่ช่วยทำ DI ให้โดยอัฒโนมัติ ซึ่งใน ASP.NET Core นั้นมี Build-In IoC Container (DI Container) ให้เราพร้อมใช้ได้อย่างรวดเร็วเลยครับ ช่วยลดขั้นตอน ลด Code ในการพัฒนา DI ลงไปได้เยอะมาก เพียงแต่เราจะต้องเรียนรู้การจัดการ State ของ Components ในขั้นตอนนี้ที่เรียกว่า Service Lifetimes

somkiat.cc/�dependency-injection-vs-dependency-inversion/

43 of 59

Dependency

Injection (DI)

44 of 59

IoC Container (DI Container):

1.Transient Instance จะถูกสร้างใหม่ทุกครั้งที่มีการเรียกใช้งานภายในระบบ

เหมาะสำหรับการทำงานที่ Lightweight, Stateless

2. Scoped Instance จะถูกสร้างใหม่ทุกครั้งที่ Client Request เข้ามานะครับ (1 Connection = 1 Client Request)

เหมาะสำหรับการทำงานที่ต้องการเรื่องของ Stateful เช่น Entity Framework (AddDbContext)

3. Singleton Instance จะถูกสร้างแค่ครั้งแรกที่ถูกเรียก หลังจากนั้น Instance จะคงอยู่ตลอดไปจนกว่าเราจะปิดและเปิดระบบขึ้นมาใหม่ เหมาะสำหรับบางงานที่ต้องการ Reuse Instance เดิมอยู่ตลอด เช่น Logging, Caching

1.Transient

Instance จะถูกสร้างใหม่ทุกครั้งที่มีการเรียกใช้งานภายในระบบ

เหมาะสำหรับการทำงานที่ Lightweight, Stateless

เราสามารถใช้คำสั่ง AddTransient เพื่อทำ DI แบบ Transient Lifetime ได้ครับ

Transient services จะถูก Disposed หลังจากที่จบ 1 Request แล้วเสมอ

2. Scoped

Instance จะถูกสร้างใหม่ทุกครั้งที่ Client Request เข้ามานะครับ (1 Connection = 1 Client Request)

เหมาะสำหรับการทำงานที่ต้องการเรื่องของ Stateful เช่น Entity Framework (AddDbContext)

เราสามารถใช้คำสั่ง AddScoped เพื่อทำ DI แบบ Scoped Lifetime ได้ครับ

Scoped services จะถูก Disposed หลังจากที่จบ 1 Client Request แล้วเสมอ

3. Singleton

Instance จะถูกสร้างแค่ครั้งแรกที่ถูกเรียก หลังจากนั้น Instance จะคงอยู่ตลอดไปจนกว่าเราจะปิดและเปิดระบบขึ้นมาใหม่

เหมาะสำหรับบางงานที่ต้องการ Reuse Instance เดิมอยู่ตลอด เช่น Logging, Caching

เราสามารถใช้คำสั่ง AddSingleton เพื่อทำ DI แบบ Singleton Lifetime ได้ครับ

45 of 59

ผลลัพธ์ออกมาว่าทุกครั้งที่ Initiate Instance จะได้ผลลัพธ์ที่แตกต่างกันคือ ถ้าเป็น Transient นั้น แต่ละ Instance จะใช้ State แยกกัน ค่าเลยไม่เพิ่มขึ้นเลย คงที่ (1), ถ้าเป็น Scoped นั้น Instance จะใช้ State ร่วมกันใน 1 Client Request ค่าเลยเพิ่มขึ้นได้จนถึงจุดที่จบ Client Connection เท่านั้น (1–4) พอมี Connection ใหม่ค่าก็เริ่มต้นใหม่, ถ้าเป็น Singleton คือทุก Instances จะใช้ State ร่วมกันตลอด ค่ามันเลยเพิ่มขึ้นเรื่อยๆ (1-N)

1 of 59

2 of 59

3 of 59

4 of 59

5 of 59

6 of 59

7 of 59

8 of 59

9 of 59

10 of 59

11 of 59

12 of 59

13 of 59

14 of 59

15 of 59

16 of 59

17 of 59

18 of 59

19 of 59

20 of 59

21 of 59

22 of 59

23 of 59

24 of 59

25 of 59

26 of 59

27 of 59

28 of 59

29 of 59

30 of 59

31 of 59

32 of 59

33 of 59

34 of 59

35 of 59

36 of 59

37 of 59

38 of 59

39 of 59

40 of 59

41 of 59

42 of 59

43 of 59

44 of 59

45 of 59

46 of 59

47 of 59

48 of 59

49 of 59

50 of 59

51 of 59

52 of 59

53 of 59

54 of 59

55 of 59

56 of 59

57 of 59

58 of 59

59 of 59