└── README.md


/README.md:
--------------------------------------------------------------------------------
 1 | # Domain-driven JavaScript
 2 | 
 3 | [Domain-driven design](http://en.wikipedia.org/wiki/Domain-driven_design) for JavaScript and Node.js.
 4 | 
 5 | Apply Domain-driven Design to the Core Domain. That part of the business Domain that is of primary importance to the success of the organisation.
 6 | 
 7 | ## Ubiquitous Language
 8 | 
 9 | Shared language within a single Bounded Context.
10 | 
11 | Used to drive the design of the Domain Model and API.
12 | 
13 | ## Bounded Contexts
14 | 
15 | Provides a boundary around an application or system within which a Domain Model exists. Constraining a Ubiquitous Language such that terms and phrases have a specific meaning within it.
16 | 
17 | **Example:** A `Product` in an e-commerce application may have a different meaning in a catalog context, an inventory context and an invoicing context.
18 | 
19 | ## Context Maps
20 | 
21 | # Tactical Modeling
22 | 
23 | Applied within a Bounded Context, using DDD’s building block patterns.
24 | 
25 | ## Entities
26 | 
27 | Are distinguishable from each other due to their unique identity. Rather than their attributes.
28 | 
29 | Can be continuously changed over a long period of time.
30 | 
31 | ## Value Objects
32 | 
33 | ## Aggregates
34 | 
35 | An Aggregate is composed of either a single Entity or a cluster of Entities and Value Objects that must remain transactionally consistent throughout the Aggregate’s lifetime.
36 | 
37 | Instances are persisted using a Repository.
38 | 
39 | Publish Domain Events.
40 | 
41 | ## Domain Services
42 | 
43 | Domain logic, domain-specific operations and process that doesn't naturally fit within Aggregates, Entities or Value Objects should be grouped within a Domain Service. 
44 | 
45 | Domain Services are stateless.
46 | 
47 | Publish Domain Events to indicate the occurrence of significant happenings in the domain. To notify external parties to changes that have occured.
48 | 
49 | ## Domain Events
50 | 
51 | Inform something that has already happened.
52 | 
53 | Must be in the past tense and cannot fail.
54 | 
55 | May be used to notify external Bounded Contexts, or provide notifications for integration with interested third parties. 
56 | 
57 | Allow an Event-Driven Architecture and eventual consistency between Aggregates and/or Bounded Contexts.
58 | 
59 | ## Application Services
60 | 
61 | Application Services are the direct clients of the domain model. Responsible for task coordination of use case flows, security, authorisation and transactions. 
62 | 
63 | No domain business logic should exist in Application Services. Instead, push them into the domain model; within Aggregates, Value Objects or Domain Services.
64 | 
65 | Provide the API through which external consumers may use the core domain. Application Services may expose functionality through functions accepting primitive types, or possibly DTOs. Alternatively, and preferrably, they will accept Command objects.
66 | 
67 | ## Infrastructure Services
68 | 
69 | Used to abstract technical concerns (e.g. MSMQ, email provider, etc).
70 | 
71 | ## Commands
72 | 
73 | > Encapsulate a command request as an object. Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
74 | 
75 | Commands capture the user's intent. 
76 | 
77 | They are named in the imperative: create account; upgrade customer; complete checkout.
78 | 
79 | A command can fail, or be declined.
80 | 
81 | Command instances may be passed to an Application Service method. Or published onto a message queue to be dispatched to a Command Handler. These handlers are semantically equivalent to an Application Service method.
82 | 
83 | ## Infrastructure
84 | ### Repositories
85 | ### Event Publishing
86 | 
87 | ## Architecture
88 | ### Hexagonal (Ports and Adapters)
89 | 
90 | Input and output ports to facilitate communication with the core Domain Model. 
91 | 
92 | Adapters are created for each I/O port and consumer. Siting between clients, on the outside, and the core, on the inside.
93 | 
94 | Inputs: HTTP (REST, SOAP), message queue (AMQP)
95 | Outputs: persistence, messaging
96 | 
97 | ### Command-Query Responsibility Segregation (CQRS)
98 | 
99 | Separate write operations (commands) from reads (queries).


--------------------------------------------------------------------------------