#DDD
Ronald Brachetti
@rbra_
#hex. architecture
#Feature Teams
# topics
- me
- motivation
- ddd
- hexagonal architecture
- example implementations
- discussion
# me
- Ron =)
- Freelancer
- Full Stack Dev
- backend focus
- clean code/architecture/performance
- social aspects of coding
- Experience w/ "heaps of stacks"
- married on Star Wars Day ;-)
# Motivations
- (Most) Applications within your codebase are monoliths right now
- different teams / same codebase / same database
- fractured code
- fractured meaning / domain knowledge
- code quality problems arise
- merge conflicts -> less refactoring -> un-clean code
- risks of diverse technology stacks
- separation of concerns
- DRY (behavior)
technical aspects
# Motivations
- Conway's Law [Conway68]
Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.
- requirements change within certain context
- a fact we we just mapped to feature teams
- inconsistent/incongruent language
- "user" in context of account, message,
payment, etc.
- "user" in context of account, message,
social aspects
# Motivations
what actually happens
# DDD
books
Eric Evans, 2004
Vaughn Vernon, 2013
# key concepts
- ubiquitous language
- model driven development
- entity, value objects, aggregate
- bounded contexts
- context maps
# key concepts
# key concepts
# why is that so powerful?
- Unambigous terms within domain
- less friction, technical and social
- Clear paths / language between domains
- again: less friction, technical and social
- reduced complexity reduces other things as well
- e.g. on-boarding, documentation, BDD
# Hexagonal Architecture
aka Ports & Adapters
Alistair Cockburn, 2005
http://a.cockburn.us/1807
# Aspects
- symmetric layouting of an application / bounded context
- clear separation of domain and adapters
- several adapters for services/ports
- hence, ability to develop test-driven properly
Symmetries, do they improve the design?
# TDD
# why is that so powerful?
- Clear separation of concerns
- As a developer, I know where to expect/put stuff
- Full test coverage of your domain
- Consistency!
- Upgrade path for breaking API changes
Focus on domain instead of database - Change a stack
- does not necessarily
mean new server!
# Layers, we're doing them!
# Really?
Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.
# how to do it?
# only for web/api? No!
example for an android app
# details please!
- port-adapters and core share interface layer
- interface layer contains
- "Use Case"-Services
- Model interfaces
- Exceptions
- ports also correlate with libraries containing necessary model interfaces
- makes communication MUCH easier
# Conclusion
- improves team work through language
- focus on domain aspects
- patterns for coop between domains
- perfect for feature teams
DDD
- improves technical structure
- focus on domain aspects
- helps to maintain consistency
- separation of use case services and utility toolbelt
- "I know where to put it"
- Testability! Clean Code! Woohoo!
- feasible road to microservices
- also through refactoring ...
- perfect for feature teams
hex. arch
# glossary
- aggregate a cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the aggregate, designated as the root. [..]
- bounded context The delimited applicability of a particular model. [It] gives team members a clear and shared understanding of what has to be consistent and what can develop independently.
- context the setting in which a word or statement appears that determines its meaning
- context map A representation of the bounded contexts involved in a project and the actual relationships between them and their models
- domain a sphere of knowledge, influence or activity
- domain expert A member of the software project whose field is the domain of the application, rather than software development. Not just any user of the software, the domain expert has deep knowledge of the subject
- entity An object fundamentally defined not by its attributes, but by a thread of continuity and identity.
- model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
-
model-driven design A design in which some subset of software elements corresponds closely to elements of a model.
Also, a process codeveloping a model and an implementation that stay aligned with each other
# glossary
- repository A mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects.
- service An operation offered as an interface that stands alone in the model, with no encapsulated state.
- 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.
- value object An object that describes some characteristics or attribute but carries no concept of identity.
# glossary
#DDD Ronald Brachetti @rbra_ #hex. architecture #Feature Teams
DDD and Hexagonal Architecture in Feature Teams
By rbrachetti
DDD and Hexagonal Architecture in Feature Teams
- 1,690
