Domain Driven Design (DDD) focuses on building applications around business domains and domain logic. It defines common building blocks like entities, value objects, aggregates, services, repositories, and factories. The document discusses these building blocks and how DDD principles like bounded context and the onion architecture can be applied using Angular, with domains and core business logic at the center and infrastructure and APIs on the outside layers. Services, observables, and factories in Angular map to repositories, domain events, and factories in DDD.

1. 1
Domain Driven Design
for Angular

2. Discussion Agenda
• What is DDD?
• Business Application Practices
• Onion Architecture
• Dependency Inversion Principle
• Building Blocks
–Entities
–Value Objects
–Aggregates
–Factories
–Services
–Repositores
–Domain Events
2

3. What is Domain Driven Design?
3
A domain is a “sphere of knowledge or activity around which application
logic revolves”.
In DDD, we seek to isolate our business realm of operation [our domain]
and design an application tailored to it.
To do this, we must define the domain layer or domain logic, AKA
‘business logic’.
DDD lets us build a custom app suited to our domain layer.

4. Business Practices for Focusing on the Core Domain
4
•Context: The setting in which a word or statement appears that
determines its meaning. Statements about a model can only be
understood in a context.
•Model: A system of abstractions that describes selected aspects of
a domain and can be used to solve problems related to that domain.
•Ubiquitous Language: A language structured around the domain
model and used by all team members to connect all the activities of the
team with the software.
•Bounded Context: A description of a boundary (typically a
subsystem, or the work of a specific team) within which a particular
model is defined and applicable.

5. Onion Model for DDD
5

6. Onion Model for DDD
6
• The Core contains the building blocks not
specific to any domain or technology. The core
contains domain objects such as entities, value
objects, custom types and aggregates.
• The Domain contains all business logic.
Classes and methods should be named using
the ubiquitous language for the domain.
• The API contains methods which can be used
to access the core and domain objects
(repositories, etc)
• The Infrastructure is a bridge between domain
objects and any infrastructure (typically
databases). This layer contains adapters which
connect the domain to any databases or
services.

7. Dependency Inversion Principle
7
Dependency Inversion forms the I in SOLID design:
“Interface Segregation Principle”
Sockets isolate what is behind the wall, on the other end of the plug, etc.
Angular Dependency Injection lets us “plug in” modules to our code,
like the USB plugs in the picture.

8. Building Blocks of DDD
8
Domain Driven Design
defines high level concepts
which can be used to create
and work with Domain
Models

9. Building Blocks of DDD - Entity
9
Entity
An object that is identified by its consistent thread of continuity,
as opposed to traditional objects, which are defined by their
attributes.
Entities are defined in interfaces. Entities are data models.
Reducers are Entity Adapters.

10. Building Blocks of DDD – Value Object
10
Value Object
An immutable (unchangeable) object that
has attributes, but no distinct identity.
Value Objects are defined as constants or in config tags. Value
Objects can be data models.
Value Objects are part of the core business logic.

11. Building Blocks of DDD – Domain Event
11
Domain Event
An object that is used to record a discrete event related to model
activity within the system. While all events within the system could
be tracked, a domain event is only created for event types which
the domain experts care about.
Observables in Angular [event system, HTTP service] are examples of Domain
Events.

12. Building Blocks of DDD – Aggregate
12
Aggregate
A cluster of entities and value objects with defined boundaries
around the group. Rather than allowing every single entity or value
object to perform all actions on its own, the collective aggregate of
items is assigned a singular aggregate root item. Now, external
objects no longer have direct access to every
individual entity or value object within the aggregate, but
instead only have access to the single aggregate root item, and
use that to pass along instructions to the group as a whole.
Grouped UI data objects are Aggregates

13. Building Blocks of DDD – Service
13
Service
Essentially, a service is an operation or form of business logic
that doesn’t naturally fit within the realm of objects. In other
words, if some functionality must exist, but it cannot be related to
an entity or value object, it’s probably a service.
Angular Services implement this building block!

14. Building Blocks of DDD – Repository
14
Repository
Not be confused with common version control repositories,
the DDD meaning of a repository is a service that uses a global
interface to provide access to all entities and value objects that
are within a particular aggregate collection. Methods should be
defined to allow for creation, modification, and deletion of objects
within the aggregate. However, by using
this repository service to make data queries, the goal is to
remove such data query capabilities from within the business logic
of object models.
Angular Services are used to create Repositories

15. Building Blocks of DDD – Factory
15
Factory
As we’ve discussed through a number of design patterns articles
already, DDD suggests the use of a factory, which encapsulates the
logic of creating complex objects and aggregates, ensuring that the
client has no knowledge of the inner-workings of object manipulation.
Angular Factories are similar to Services, but create and enhance
(map, convert properties, lookup, etc) objects before returning them.