Domain-Driven Design: Difference between revisions
Jump to navigation
Jump to search
(3 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
* [[Software Architecture#Subjects|Software Architecture]] | * [[Software Architecture#Subjects|Software Architecture]] | ||
* [[Software_Development#Domain-Driven_Design|Software Development]] | * [[Software_Development#Domain-Driven_Design|Software Development]] | ||
* [[Design_Patterns#Pattern_Hierarchy|Design Patterns]] | |||
=To Read= | |||
* [[DDD|Domain Driven Design Tacking Complexity In The Heart Of Software]] by Eric Evans | |||
* [https://www.amazon.com/Learning-Domain-Driven-Design-Aligning-Architecture/dp/1098100131/ Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy] by Vlad Khononov | |||
=Overview= | =Overview= | ||
Line 18: | Line 23: | ||
==Ubiquitous Language== | ==Ubiquitous Language== | ||
==Domain Model== | ==Domain Model== | ||
=Organizatorium= | |||
* https://dev.to/flbenz/kotlin-and-domain-driven-design-value-objects-4m32 |
Latest revision as of 21:34, 16 February 2024
Internal
To Read
- Domain Driven Design Tacking Complexity In The Heart Of Software by Eric Evans
- Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy by Vlad Khononov
Overview
An application's domain is the subject area the application addresses. The application's domain defines the ideas and concepts that influence the understanding of the application. The domain is modeled in the application by domain model objects, usually maintained under a "model" subdirectory in the source tree.
Parse DDD.
Concepts
Service
An operation offered as an interface that stands along in the model, with no encapsulated state. Also see @Service stereotype.