The document discusses domain-driven design and focuses on properly modeling the domain or business area that a software application aims to support. It emphasizes making the software a reflection of the key concepts and elements in the domain. The whole domain is composed of subdomains, including core, supporting, and generic subdomains. Strategic design patterns like using a ubiquitous language, defining bounded contexts, and mapping relationships between contexts are also covered. Tactical patterns like modeling entities, value objects, aggregates, and using domain events are described. The goal is to enhance the domain by building software that precisely represents the domain.

1. Domain Driven Design
Arch CoP
14/08/2023

2. Focus on Domain
When we begin a software project, we should focus on the domain it is
operating in.
A domain is a sphere of
knowledge, influence, or
activity. It is the business
area of focus for the
application developer.
Valuation Domain
Persona:
 Fund/Portfolio manager
 Debt fund manager
 Head of real estate lending
 Appraiser
 Broker
Equity Investors need to manage the valuation of their assets, loans, and investments
to support better and more timely decision-making.

3. Focus on Domain (cont.)
How can we make the software fit harmoniously with the domain?
 Make software a reflection of the
domain.
 Software needs to incorporate the core
concepts and elements of the domain,
and to preciously realize the
relationships between them.
 The entire purpose of the software is to
enhance a specific domain.

4. A Core Domain is a part of the
business Domain that is of
primary importance to the
success of the organization.
Supporting Subdomain
Generic Subdomain
Supplemented by
Domains, Subdomains
The whole Domain of the organization is composed of Subdomains.
 If a subdomain models some aspect of the business that is essential, yet not core, then it is a Supporting
Subdomain. The business creates a Supporting Subdomain because it is somewhat specialised.
 If a subdomain captures nothing special to the business, yet it is required for the overall business
solution, then it is a Generic Subdomain.

5. Domains, Subdomains - example
Domain
Valuation Context
Valuation Manage
ment (Core)
Collaboration
Context
Guest Collaboration
(Supporting)
Identity and
Access Context
Identity and
Access (Generic)

6. Strategic Design
Patterns –
Ubiquitous
Language
Common
Language
Domain Expert
Developers Architect
Testers
• A core principle of DDD is to use a language based on the model.
• The Ubiquitous Language connects all the parts of the design and
creates the premise for the design team to function well.

7. Strategic Design
Patterns –
Bounded
Context
A Bounded Context is an explicit boundary
within which a domain model exists.
Valuation Context
Identity and
Access Context
User Role
Portfolio
Manager
Broker
Appraiser
Portfolio Property
Workflow
Investor
Report
Modeling
Permissions

8. Strategic Design
Patterns –
Bounded
Context
Inside the boundary all terms and phrases of the
Ubiquitous Language have specific meaning.
In Valuation Context, Domain Experts don't describe the people who does
the valuation as Users with Permissions. They talk about these people in
terms of the roles they play in the Valution context, like, Fund/Portfolio
Manager, Appraiser, Broker.
On the other hand, it's in an Identity and Access Context that we talk about
Users. In this context, User objects have usernames, and detailed
information about the individual person.
We do not create an Appraiser object out of thin air. Every Appraiser must
be prequalified. We confirm the existence of a User playing the appraiser
Role within Identitiy and Access context.
The attributes of an authentication descriptor are passed with requests to
the Identity and Access context. To create a new Appraiser object in
Valution context, a subset of User attributes and a Role are used.

9. Strategic Design
Patterns –
Bounded
Context
Domain
Valuation Context
Valuation
Management (Core)
Collaboration
Context
Guest Collaboration
(Supporting)
Identity and
Access Context
Identity and
Access (Generic)

10. Strategic Design
Patterns –
Context Maps
Domain
Valuation Context
Collaboration
Context
Identity and
Access Context
Identity and
Access (Generic)
Context Maps show the relationships among
Bounded Context.
ACL
ACL
OHS/PL
OHS/PL
U
U
D
U
D
ACL
U = Upstream
D = Downstream
ACL = Anti-Corruption Layer
OHS = Open Host Service
PL = Published Language

11. Tactical Design
Patterns
<<entity>>
Organization
<<domain event>>
OrgProvisionedEvent
<<domain event>>
OrgUpdatedEvent
Delivery & CS Context
<<value object>>
ContactInformation
<<aggregate root>>
User
<<entity>>
Person
Identity and Access Context
<<entity>>
Role
<<entity>>
ServiceContract
<<value object>>
ContractDuration
<<domain event>>
UserProvisionedEvent
<<domain event>>
UserDeactivatedEvent

12. Tactical Design
Patterns
An Entity is a unique thing and is capable of being changed continuously over a
period. Changes can be so extensive that the object might seem much different
from what it once was. Yet it is the same object by identity (Unique Identity).
Value Objects are a vital building block of DDD. Examples of objects that are
commonly modeled as Value Objects are numbers (3, 10, 294.34); text strings;
dates; times; currencies; postal addresses; phone numbers. Benefits of using
Value Objects – easy to create, test, use, optimise, and maintain.
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.
An instance of an Aggregate is persisted using its Repository and later searched
for within and retrived from it.
Use stateless Services inside the domain model to perform business operations
that don't fit naturally as an operation on an Entity or a Value Object.
Use Domain Events to indicate the occurance of significant happening in the
domain.

13. Thank You