DDD guide - 版本历史

Riguz：/* Layers in DDD */

2025-08-26T12:41:02Z

Layers in DDD

←上一版本		2025年8月26日 (二) 12:41的版本
第39行：		第39行：
	</syntaxhighlight>		</syntaxhighlight>

	Dependency rule:		Dependency rule<ref>https://khalilstemmler.com/wiki/dependency-rule/</ref>:

	[[Image:ddd-dependency-rule.svg\|600px]]		[[Image:ddd-dependency-rule.svg\|600px]]

Riguz：/* Layers in DDD */

2025-08-26T12:40:19Z

Layers in DDD

←上一版本		2025年8月26日 (二) 12:40的版本
第38行：		第38行：
	└── mapper		└── mapper
	</syntaxhighlight>		</syntaxhighlight>

			Dependency rule:

			[[Image:ddd-dependency-rule.svg\|600px]]

	=== Domain Layer ===		=== Domain Layer ===
	The domain layer contains the core business logic and domain models.		The domain layer contains the core business logic and domain models.

Riguz：/* Layers in DDD */

2025-08-17T14:00:36Z

Layers in DDD

←上一版本		2025年8月17日 (日) 14:00的版本
第19行：		第19行：

	== Layers in DDD ==		== Layers in DDD ==
			<ref> https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice</ref>

	<syntaxhighlight lang="cpp">		<syntaxhighlight lang="cpp">
	com.example.todo		com.example.todo

Riguz：/* Should I handle messages in repository? */

2025-07-30T03:30:07Z

Should I handle messages in repository?

←上一版本		2025年7月30日 (三) 03:30的版本
第236行：		第236行：
	* For non-domain purposes (e.g., rate limiting, session storage), handle Redis interactions directly in the infrastructure or application layer.		* For non-domain purposes (e.g., rate limiting, session storage), handle Redis interactions directly in the infrastructure or application layer.
	* Always keep the domain layer free of Redis-specific logic to maintain separation of concerns.		* Always keep the domain layer free of Redis-specific logic to maintain separation of concerns.

			== Do I need a service layer? ==
			Whether you need a service layer depends on the complexity of your application and how you structure your code. In Domain-Driven Design (DDD), the service layer (often referred to as the application layer) plays an important role in coordinating use cases and workflows.

			You might skip the service layer if:

			* Your application is simple
			* Your domain logic is self-contained

	[[Category:DDD]]		[[Category:DDD]]
	[[Category:MicroService]]		[[Category:MicroService]]

Riguz：/* Should I handle messages in repository? */

2025-07-30T03:25:06Z

Should I handle messages in repository?

@@ 第224行： / 第224行： @@
 Message brokers like Kafka, RabbitMQ, or others are not persistence mechanisms in the traditional sense but are instead used for communication and event-driven architectures. Therefore, creating a repository for a message broker is generally not recommended. Instead, you should handle message brokers in the application layer or infrastructure layer.
 [[Category:DDD]]
 [[Category:MicroService]]

Riguz：/* Should I have a save() method in domain model */

2025-07-30T03:23:00Z

Should I have a save() method in domain model

←上一版本		2025年7月30日 (三) 03:23的版本
第220行：		第220行：

	No, the domain model (Todo) should not have a save() method. In Domain-Driven Design (DDD), the domain model is responsible for encapsulating business logic and representing the core concepts of the domain. It should not be concerned with persistence or infrastructure details like saving to a database.		No, the domain model (Todo) should not have a save() method. In Domain-Driven Design (DDD), the domain model is responsible for encapsulating business logic and representing the core concepts of the domain. It should not be concerned with persistence or infrastructure details like saving to a database.

			== Should I handle messages in repository? ==

			Message brokers like Kafka, RabbitMQ, or others are not persistence mechanisms in the traditional sense but are instead used for communication and event-driven architectures. Therefore, creating a repository for a message broker is generally not recommended. Instead, you should handle message brokers in the application layer or infrastructure layer.

	[[Category:DDD]]		[[Category:DDD]]
	[[Category:MicroService]]		[[Category:MicroService]]

Riguz：/* = Should I have a save() method in domain model */

2025-07-30T03:20:26Z

= Should I have a save() method in domain model

←上一版本		2025年7月30日 (三) 03:20的版本
第217行：		第217行：
	In the repository interface (defined in the domain layer), you should use domain models because the repository is part of the domain layer and should work with the core business concepts. However, in the repository implementation (in the infrastructure layer), you can map between domain models and database entities to handle persistence.		In the repository interface (defined in the domain layer), you should use domain models because the repository is part of the domain layer and should work with the core business concepts. However, in the repository implementation (in the infrastructure layer), you can map between domain models and database entities to handle persistence.

	== Should I have a save() method in domain model =		== Should I have a save() method in domain model ==

			No, the domain model (Todo) should not have a save() method. In Domain-Driven Design (DDD), the domain model is responsible for encapsulating business logic and representing the core concepts of the domain. It should not be concerned with persistence or infrastructure details like saving to a database.

	[[Category:DDD]]		[[Category:DDD]]
	[[Category:MicroService]]		[[Category:MicroService]]

Riguz：/* Should I use domain model or database entity in repository? */

2025-07-30T03:19:56Z

Should I use domain model or database entity in repository?

←上一版本		2025年7月30日 (三) 03:19的版本
第215行：		第215行：

	== Should I use domain model or database entity in repository? ==		== Should I use domain model or database entity in repository? ==
			In the repository interface (defined in the domain layer), you should use domain models because the repository is part of the domain layer and should work with the core business concepts. However, in the repository implementation (in the infrastructure layer), you can map between domain models and database entities to handle persistence.

	== Should I have a save() method in domain model =		== Should I have a save() method in domain model =

	[[Category:DDD]]		[[Category:DDD]]
	[[Category:MicroService]]		[[Category:MicroService]]

Riguz：/* Summary */

2025-07-30T03:18:58Z

Summary

←上一版本		2025年7月30日 (三) 03:18的版本
第206行：		第206行：
	* The infrastructure layer handles persistence and maps between domain models and database entities.		* The infrastructure layer handles persistence and maps between domain models and database entities.
	* Keep the domain layer decoupled from technical concerns to ensure clean, maintainable, and testable code.		* Keep the domain layer decoupled from technical concerns to ensure clean, maintainable, and testable code.

			=FAQ =
			== Difference between repository and persistence ==
			The repository in the domain layer and the persistence layer in the infrastructure serve different purposes and are part of the separation of concerns in DDD.

			* The repository in the domain layer is an abstraction (interface) that defines how the domain interacts with persistence.
			* The persistence layer in the infrastructure is the implementation of that abstraction, handling the actual database operations.

			== Should I use domain model or database entity in repository? ==
			== Should I have a save() method in domain model =

	[[Category:DDD]]		[[Category:DDD]]
	[[Category:MicroService]]		[[Category:MicroService]]

Riguz：/* Layers in DDD */

2025-07-30T03:15:03Z

Layers in DDD

←上一版本		2025年7月30日 (三) 03:15的版本
第19行：		第19行：

	== Layers in DDD ==		== Layers in DDD ==
	=== 1. Domain Layer ===		<syntaxhighlight lang="cpp">
			com.example.todo
			├── application
			│ ├── service
			│ └── dto
			├── domain
			│ ├── model
			│ ├── repository
			│ └── service
			├── infrastructure
			│ ├── persistence
			│ ├── messaging
			│ └── configuration
			└── interface
			├── controller
			└── mapper
			</syntaxhighlight>
			=== Domain Layer ===
	The domain layer contains the core business logic and domain models.		The domain layer contains the core business logic and domain models.

第58行：		第75行：
	</syntaxhighlight>		</syntaxhighlight>

	=== 2. Application Layer ===		=== Application Layer ===
	The application layer coordinates use cases and orchestrates interactions between the domain and infrastructure layers.		The application layer coordinates use cases and orchestrates interactions between the domain and infrastructure layers.

第81行：		第98行：
	</syntaxhighlight>		</syntaxhighlight>

	=== 3. Infrastructure Layer ===		=== Infrastructure Layer ===
	The infrastructure layer handles technical concerns like persistence, messaging, and external APIs.		The infrastructure layer handles technical concerns like persistence, messaging, and external APIs.

DDD guide - 版本历史

Riguz：​/* Layers in DDD */

Riguz：​/* Layers in DDD */

Riguz：​/* Layers in DDD */

Riguz：​/* Should I handle messages in repository? */

Riguz：​/* Should I handle messages in repository? */

Riguz：​/* Should I have a save() method in domain model */

Riguz：​/* = Should I have a save() method in domain model */

Riguz：​/* Should I use domain model or database entity in repository? */

Riguz：​/* Summary */

Riguz：​/* Layers in DDD */

Riguz：/* Layers in DDD */

Riguz：/* Layers in DDD */

Riguz：/* Layers in DDD */

Riguz：/* Should I handle messages in repository? */

Riguz：/* Should I handle messages in repository? */

Riguz：/* Should I have a save() method in domain model */

Riguz：/* = Should I have a save() method in domain model */

Riguz：/* Should I use domain model or database entity in repository? */

Riguz：/* Summary */

Riguz：/* Layers in DDD */