25 Commands: Application Service Patterns for Processing Business Use Cases
WHAT’S IN THIS CHAPTER?
- A discussion of the differences between application logic and domain logic
- Examples of concerns that are handled in the service layer
- Design patterns that can be applied to application services
- Suggestions for testing application services
Wrox.com Code Downloads for This Chapter
The wrox.com code downloads for this chapter are found at www.wrox.com/go/domaindrivendesign on the Download Code tab. The code is in the Chapter 25 download and individually named according to the names throughout the chapter.
Many of Domain-Driven Design (DDD’s) benefits arise from disciplined use of a project’s ubiquitous language (UL)—both in conversation and in code. One of the big challenges you face, though, is maintaining explicitness of domain concepts in code as you try to keep them isolated from purely technical concerns. For instance, when you are knowledge-crunching with domain experts, talking them through your domain model, it’s not ideal to clutter your thinking—or the conversation—with threads, sockets, or database connections. Therefore, to maximize the explicitness of your domain model, a clear separation between real-world domain concepts and purely technical concerns is highly desirable. This separation is one of the important roles carried out by application services, which belong to the application service layer.
Logically, the application service layer sits above the domain and ...
Get Patterns, Principles, and Practices of Domain-Driven Design now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
