A beautiful journey to writing wise code that works

• The source code structure should be as clear as a book’s table of contents, making it easy to understand the domain and system.
• Test code should act as a manual for understanding business rules.

Application Architecture

Internal Architecture (Hexagonal Architecture)

External Architecture

Hands-on Labs

I restructured 'Getting Started: Domain-Driven Design' based on the design principles and practices I defined.

Goal

• Understand code structuring for sustainable software development.
• Learn tactical design that express domain knowledge as code.

Table of Contents

• Part 1. VOC
  • Chapter 01. Domain Exploration
  • Chapter 02. Domain Structuring
  • Chapter 03. Usecase Exploration
  • Chapter 04. Usecase Pipeline
  • Chapter 05. Cucumber
• Part 2. Monolithic
  • Chapter 06. WebApi
  • Chapter 07. OpenTelemetry
  • Chapter 08. PostgreSQL
  • Chapter 09. Cache
  • Chapter 10. Containerization
• Part 3. Microservices
  • Chapter 11. Aspire
  • Chapter 12. RabbitMQ
  • Chapter 13. Resilience
  • Chapter 14. Reverse Proxy
  • Chapter 15. Chaos Engineering
• Part 4. Operations
  • Chapter 16. Feature Flag Management
  • Chapter 17. Observability System
  • Chapter 18. Infrastructure as Code

Solution Design Principles

1. Separation
   • Concern: Business Concerns vs Technical Concerns
   • Goal: Main Goals vs Accompanying Goals (It refers to a goal that is naturally carried out or plays a supporting role in the process of achieving the main goal. 부수 목표: 주가 되는 것에 붙어 따르는 것)
2. Direction
   • Top: The more important thing from a technical concern(Accompanying Goal).
   • Down: The more important thing from a business concern(Main Goal).

Direction	Separation of Concerns	Separation of Goals
Top	Technical Concerns (Infinite)	Accompanying Goals (Infinite -Abstractions-> Finite)
Down	Business Concerns (Finite)	Main Goals (Finite)

• To intuitively understand the main goals of a layer, accompanying goals are placed inside the Abstractions folder, leaving only the main goals at the top level.
• This helps clearly distinguish between the main and accompanying goals, making them easier to understand.

{T}
├─Src
│  ├─{T}                          // Host               > Top: Technical Concerns (Accompanying Goal)
│  ├─{T}.Adapters.Infrastructure  // Adapter Layer      >  │
│  ├─{T}.Adapters.Persistence     // Adapter Layer      >  │
│  ├─{T}.Application              // Application Layer  >  ↓
│  └─{T}.Domain                   // Domain Layer       > Down: Business Concerns (Main Goal)
│     │
│     ├─Abstractions                                    > Top: Technical Concerns (Accompanying Goal)
│     │                                                 >  ↓
│     └─AggregateRoots                                  > Down: Business Concerns (Main Goal)
│
└─Tests
   ├─{T}.Tests.Integration        // Integration Test   > Top: Technical Concerns (Accompanying Goal)
   ├─{T}.Tests.Performance        // Performance Test   >  ↓
   └─{T}.Tests.Unit               // Unit Test          > Down: Business Concerns (Main Goal)