The Trinity Architecture proposed here is an architectural pattern for backend enterprise applications. It emanates from a typical 4-layers architecture employing the Dependency Inversion Principle (DIP). It is ideal for, but not limited to, Domain-Driven Design (DDD) applications. The three pillars of Trinity are: the Domain Model (DOMAIN), the public Application Programming Interface (API), and the Auxiliary Services (AUX). Trinity emphasizes on balancing uncontrolled flexibility with consistency. It provides specific implementation guidelines with eight top modules.

1. The Trinity
Architecture
Christos Tsakostas
DDD Greece, May 10th 2019, e-food, Athens

3. Agenda
- Introduction
- Brief overview of architectural patterns
- Formation of Trinity
- Conclusions & More

4. Introduction

5. What is Architecture? (Fowler, 2002)
1. Breakdown of a system into its
parts
2. Subjective decisions about the
form & structure of parts

6. Architecture Classifications
System
Enterprise
SecuritySecurity
Solution
Event-Driven
Data-centric
Cloud Persistence
BusinessApplication
Monolith
Microservices
...
...
...
...
...
...
...
...

7. 4+1 Architectural View Model (Kruchten, 1995)

8. The term Architecture in this context
Enterprise (microservice)
applications architecture

9. The Architecture Problem
- Choice of pattern
- Structure of parts
- Consistent
- Long-lasting
- Scalability
- Interchangeable parts

10. What are teams doing now?
- Little or no architectural design (i.e. start-ups, side-projects etc.)
- The majority uses layered architectures
- Some teams use modern architectures (such as Ports-Adapters)

11. Intentions of the Trinity Architecture
- Agile
- Consistent
- Recognizable

12. Brief Overview
of Popular
Architectural
Patterns

13. Timeline of Applications Architecture
- Optimizations of data structures and algorithms (50’s/60’s-80’s)
- Multi-Tier (90’s)
- Multi-Layered (90’s - today)
- DIP*-Based (2000’s - today)
- Less popular patterns, such as Data - Context - Interaction / DCI (2000’s)
*: Dependency Inversion Principle

14. The
Multi-Layered
Architecture

15. Layered: Most Prevalent Architecture of All Times
- 3-Layers (i.e. Martin Fowler 2002)
- 4-Layers (i.e. Eric Evans 2003)
- Some teams use more than 10 layers!

16. Typical 3-Layers Architecture (Fowler, 2002)

17. Typical 4-Layers Architecture (Evans, 2003)

18. Benefits of Layered Architectures
- Simplicity
- Consistency
- Separation of Concerns

19. Drawbacks of Layered Architectures
- Lack of inbuilt scalability
- Hidden use cases
- Business Logic may spread out from UI to Database
- Frameworks & Technologies not easily interchangeable
- Complex Testing Processes
- Risk of too many, unnecessary, layers

20. What is the “Dependency Inversion Principle”?

21. The Dependency Inversion Principle (DIP)

22. DIP Example

23. DIP Layered Architecture (Vaughn Vernon, 2013)

24. The DIP-based
Architectures

25. DIP-Based Architectures
- Hexagonal Ports-Adapters by Alistair Cockburn, 2005
- Onion by Jeffrey Palermo, 2008
- Clean Architecture by Robert C. Martin, 2012 / 2017

26. Hexagonal Ports-Adapters

27. Onion

28. Clean Architecture

29. Benefits of DIP-Based Architectures
- Independent of the UI
- Independent of the database and other external systems
- Independent of technology specific libraries and frameworks
- Interchangeable infrastructure modules
- Arbitrary number and types of clients
- Testable

30. Drawbacks of DIP Architectures
- Complexity
- Vague Terminology (at least for DDD)
- Lack of project structure templates (except Onion)
- Therefore, vulnerable to erroneous dependencies and modules structure
- How to choose a pattern?

31. Formation of
Trinity
Architecture

32. The Steps to Build Trinity
- Start from Typical 4-Layers and define Generic vs Specific Layers
- Define Strict and Relaxed Dependencies
- Apply DIP
- Include Application Module
- Finalize

33. 1: Define Generic vs Specific Layers

34. 2: Define Strict & Relaxed Dependencies

35. 3: Apply DIP

36. 4: Include Application (APP) Module

37. 5: Rotate and form the Trinity Architecture

38. Alternative Circular View of Trinity

39. Sample API Clients

40. Sample Auxiliary Details

41. Sample Domain Details

42. Demo Project Layout

43. Comparisons

44. Hexagonal Ports-Adapters

45. Comparison to Hexagonal Ports-Adapters

46. Conclusions

47. Balances Consistency with Agility
Consistency:
- Eight top modules
- Rigorous module dependencies
Agility:
- Numerous API Clients
- Numerous Auxiliary Details
- Numerous Domain Details

48. Frameworks Agnostic Core
- API, Auxiliary & Domain do not
depend on Frameworks
- Framework specific annotations
may optionally be used
- Testable

49. Frameworks Outside Core
- An arbitrary number of API
Clients, AUX & Domain Details
- Interchangeable Details

50. Agile. Better allocation of team members
- I.e. group working on Domain
- I.e. group working on domain
Persistence
- I.e. group working on integration
to Payment Gateways

51. Other Features
- Single Entry-Point
- Rigorous modules dependencies
- Domain model does not leak to API Clients
- Reusable AUX Details

52. Recognizable. 1:1 theory and practice

53. Fits smoothly to DDD
Trinity is in accordance to the rules of
Tactical Techniques for DDD

54. Related Tools

55. Trinity Demo in Java
Demo microservice application structured according to the Trinity Architecture.
https://github.com/oregor-projects/trinity-demo-java

56. Trinity Scaffolder for Java Projects
Scaffolder for Java applications based on the Trinity Architecture.
https://github.com/oregor-projects/trinity-scaffolder-java

57. trinity4j
A set of Domain-Driven Design Libraries for Java Applications:
https://github.com/oregor-projects/trinity4j

58. Related Work

59. DDD: “Focus on the Domain”. But, there is more...

60. https://polygenesis.io

61. Thank you!
Christos Tsakostas
https://www.linkedin.com/in/tsakostas
ct@oregor.com