Domain-Driven Design: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(6 intermediate revisions by the same user not shown)
Line 2: Line 2:


* [[Software Architecture#Subjects|Software Architecture]]
* [[Software Architecture#Subjects|Software Architecture]]
* [[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 13: Line 19:
==Service==
==Service==


An operation offered as an interface that stands along in the model, with no encapsulated state.
An operation offered as an interface that stands along in the model, with no encapsulated state. Also see [[Spring_Dependency_Injection_and_Inversion_of_Control_Container_Concepts#@Service|@Service stereotype]].
 
==Ubiquitous Language==
==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

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.

Ubiquitous Language

Domain Model

Organizatorium