# Domain Service > [!Note] > A **Domain Service** encapsulates **domain logic** that spans multiple [[Entities]] or [[Aggregates]], offering **stateless operations** that belong in the **domain layer** rather than any single object. A **Domain Service** addresses operations that don’t naturally fit within an [[Entities]] or [[Value Objects]], orchestrating workflows and enforcing **business rules** across multiple collaborators. It remains **stateless**, focusing solely on domain concerns and avoiding direct dependencies on infrastructure or application layers. By using a **clear, [[Ubiquitous Language]]**, the service communicates its purpose in the **shared language**, and its methods encapsulate significant domain behaviors. Domain Services promote **separation of concerns**, keeping complex multi-entity logic centralized and maintainable within the core model. --- ## References - Vernon, V. (2016). _Domain-driven design distilled_. Addison-Wesley Professional. - Vernon, V. (2013). _Implementing domain-driven design_. Addison-Wesley Professional. - Khononov, V. (2021). _Learning domain-driven design: Aligning software architecture and business strategy_. O’Reilly Media. - Alammar, J., & Grootendorst, M. (2024). _Hands-on large language models: Language understanding and generation_. O’Reilly Media. - Evans, E. (2003). _Domain-driven design: Tackling complexity in the heart of software_. Addison-Wesley Professional. - Millett, S., & Tune, N. (2015). _Patterns, principles, and practices of domain-driven design._ Wrox.