#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.

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

Made with Slides.com