Throughout the years, the Concentric Architectures (Onion, Hexagonal, Clean-..) have grown into the undisputed leader among backend systems architectures. With the rise of Domain-Driven Design, keeping your Domain ring 'agnostic' to the outside world has become the norm today. But history proved that any 'norm' in software architectures will cause overengineering if applied without criticism.
After a brief recap of these architectures, their pitfalls, and weaknesses, we'll see two alternatives that segregate code not in 'layers' or 'rings' but in vertical slices: Feature Slicing and Modular Monolith.
[Feature Slicing](vertical Slice Architecture) (aka *UseCase) has its own pitfalls and weaknesses, that we'll briefly review. But this will just warm us up for the next style.
Modular Monolith (aka Modulith) is an architecture style that helped many companies break their legacy codebases, and smoothly move to microservices. Most of the techniques discussed here can also come handy when one single microservice grew big and needs to be broken down.
Even more, greenfield projects today opt for this architecture instead of microservices, to avoid paying the high cost of distributability. Imagine cohesive but decoupled modules living in the same code base & deployment, but on which different teams work in harmony, delivering more value much faster than an equivalent microservice ecosystem.🦄
On the agenda:
- patterns to break data structures
- how to protect Domains inside modules
- communication patterns between modules
- breaking cyclic dependencies
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...Alex Cachia
Vertical Slice Architecture helps us build maintainable applications by separating concerns around features rather than technical responsibilities allowing us to add features without modifying existing code.
Nowadays traditional layered monolithic architecture in Java world is not so popular as 5-10 years ago. I remember how we wrote tons of code for each layer repeating almost the same parts for every application. Add unit and integration testing to understand how much time and efforts has been spent on repeatable work. All cool ideas around DDD (domain driven design) and Hexagonal Architecture was just a nice theory because reality hasn’t allow us to implement it easily. Even Dependency Injection with Spring framework was completely focused on traditional layered approach, not even talking about JavaEE platform.
Today we have Spring Boot ecosystem covering most of our needs for integration with almost all possible technologies and microservices architectural trend, enabling completely new approach to build Java applications around domain model. It is so natural to build Java domain-oriented services and connect them with external world using ports and adapters, that Hexagonal Architecture is almost enabled by default. You just need to switch your way of thinking…
Victor Rentea introduces himself as a Java Champion, trainer, and speaker who focuses on topics like Hibernate, Spring, Java 8/FP, architecture, clean code, unit testing, reactive programming, and Java performance. He advocates building a deep, rich domain model with value objects and entities that encapsulate logic and enforce invariants. The document provides guidance on applying principles like separating concerns with layers, dependency inversion, and avoiding anemic domain models in order to build flexible, testable systems that are decoupled from frameworks and external dependencies.
Domain Driven Design (DDD) is a software design approach that focuses on modeling a domain accurately. It uses ubiquitous language, bounded contexts, and explicit domain models. The key aspects of DDD include developing a shared model with domain experts, separating concerns into bounded contexts, and iteratively refining domain models through close collaboration between technical and domain teams. DDD aims to produce software designs that are more aligned with the mental models of users and stakeholders in a complex domain.
Understanding MicroSERVICE Architecture with Java & Spring BootKashif Ali Siddiqui
This is a deep journey into the realm of "microservice architecture", and in that I will try to cover each inch of it, but with a fixed tech stack of Java with Spring Cloud. Hence in the end, you will be get know each and every aspect of this distributed design, and will develop an understanding of each and every concern regarding distributed system construct.
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
No Onions, No Tiers - An Introduction to Vertical Slice Architecture by Bill ...Alex Cachia
Vertical Slice Architecture helps us build maintainable applications by separating concerns around features rather than technical responsibilities allowing us to add features without modifying existing code.
Nowadays traditional layered monolithic architecture in Java world is not so popular as 5-10 years ago. I remember how we wrote tons of code for each layer repeating almost the same parts for every application. Add unit and integration testing to understand how much time and efforts has been spent on repeatable work. All cool ideas around DDD (domain driven design) and Hexagonal Architecture was just a nice theory because reality hasn’t allow us to implement it easily. Even Dependency Injection with Spring framework was completely focused on traditional layered approach, not even talking about JavaEE platform.
Today we have Spring Boot ecosystem covering most of our needs for integration with almost all possible technologies and microservices architectural trend, enabling completely new approach to build Java applications around domain model. It is so natural to build Java domain-oriented services and connect them with external world using ports and adapters, that Hexagonal Architecture is almost enabled by default. You just need to switch your way of thinking…
Victor Rentea introduces himself as a Java Champion, trainer, and speaker who focuses on topics like Hibernate, Spring, Java 8/FP, architecture, clean code, unit testing, reactive programming, and Java performance. He advocates building a deep, rich domain model with value objects and entities that encapsulate logic and enforce invariants. The document provides guidance on applying principles like separating concerns with layers, dependency inversion, and avoiding anemic domain models in order to build flexible, testable systems that are decoupled from frameworks and external dependencies.
Domain Driven Design (DDD) is a software design approach that focuses on modeling a domain accurately. It uses ubiquitous language, bounded contexts, and explicit domain models. The key aspects of DDD include developing a shared model with domain experts, separating concerns into bounded contexts, and iteratively refining domain models through close collaboration between technical and domain teams. DDD aims to produce software designs that are more aligned with the mental models of users and stakeholders in a complex domain.
Understanding MicroSERVICE Architecture with Java & Spring BootKashif Ali Siddiqui
This is a deep journey into the realm of "microservice architecture", and in that I will try to cover each inch of it, but with a fixed tech stack of Java with Spring Cloud. Hence in the end, you will be get know each and every aspect of this distributed design, and will develop an understanding of each and every concern regarding distributed system construct.
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
The domain model is an abstraction of the problem domain that your system supports. It contains the objects and operations that are crucial to your system and its users. Therefore the design of the domain model deserves the utmost care and attention. In this session you will be introduced to Domain-Driven Design and you will learn how to put Domain-Driven Design (DDD) into practice. We will explore how to apply DDD on tactical level to design a rich domain model that encapsulates behaviour, protects its invariants and can be tested in isolation from its runtime environment
This document provides an introduction to domain-driven design (DDD). It defines DDD as an approach where the application's domain model reflects the real business domain and core domain is the primary focus. It discusses DDD principles like ubiquitous language, domain encapsulation, and technical simplicity. The benefits of DDD include improved communication through a shared language, a modular and extensible domain model, and the domain rules and logic being encapsulated in one place.
Microservice With Spring Boot and Spring CloudEberhard Wolff
Spring Boot and Spring Cloud are an ideal foundation for creating Microservices based on Java. This presentation explains basic concepts of these libraries.
The document discusses Domain-Driven Design (DDD). It explains that DDD focuses on properly modeling the problem domain and using this domain model to drive the software design. This involves developing a ubiquitous language within the bounded context of the domain model and ensuring consistency between this language, the domain model, and the software code. Patterns like entity, value object, aggregate, and repository can be used, but the domain model is the most important pattern in DDD.
A introduction to Microservices Architecture: definition, characterstics, framworks, success stories. It contains a demo about implementation of microservices with Spring Boot, Spring cloud an Eureka.
The document discusses Microservices architecture and compares it to monolithic architecture. It covers topics like infrastructure for Microservices including API gateways, service discovery, event buses. It also discusses design principles like domain-driven design, event sourcing and CQRS. Microservices are presented as a better approach as they allow independent deployments, scale independently and use multiple programming languages compared to monolithic applications.
Kevin Huang: AWS San Francisco Startup Day, 9/7/17
Architecture: When, how, and if to adopt microservices - Microservices are not for everyone! If you're a small shop, a monolith provides a great amount of value and reduces the complexities involved. However as your company grows, this monolith becomes more difficult to maintain. We’ll look at how microservices allow you to easily deploy and debug atomic pieces of infrastructure which allows for increased velocity in reliable, tested, and consistent deploys. We’ll look into key metrics you can use to identify the right time to begin the transition from monolith to microservices.
- Microservices advocate creating a system from small, isolated services that each own their data and are independently scalable and resilient. They are inspired by biological cells that are small, single-purpose, and work together through messaging.
- The system is divided using a divide and conquer approach, decomposing it into discrete subsystems that communicate over well-defined protocols. Each microservice focuses on a single business capability and owns its own data and behavior.
- Microservices communicate asynchronously through APIs and events to maintain independence and isolation, which enables continuous delivery, failure resilience, and independent scaling of each service.
Domain Driven Design and Hexagonal Architecture with RailsDeclan Whelan
You know that Domain Driven Design, Hexagonal Architecture, and the Single Responsibility Principle are important but it’s hard to know how to best apply them to Rails applications. Following the path of least-resistance will get you in trouble. In this session you will learn a way out of the “fat model, skinny controller” hell. You will leave with a roadmap to guide your design based on concepts from Domain Driven Design and Hexagonal Architecture.
The document discusses Domain Driven Design (DDD), a software development approach that focuses on building an object-oriented model of the domain that software needs to represent. It emphasizes modeling the domain closely after the structure and language of the problem domain. Key aspects of DDD discussed include ubiquitous language, bounded contexts, entities, value objects, aggregate roots, repositories, specifications, domain services, modules, domain events, and command query separation. DDD is best suited for projects with a significant domain complexity where closely modeling the problem domain can help manage that complexity.
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
Distributed Transactions is a key concept for Micro Services based Apps and Saga Design Pattern helps out over here. However, developers struggle to shift their mindset from CRUD based design to Event Sourcing / CQRS concept. To solve this problem we are introducing the concept of Event Storming and Event Storming Process map.
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
Talk built based on several of my trainings: http://www.victorrentea.ro/#training
Covers: Clean/Onion/Hexagonal Architecture, Domain Entities, Value Objects, Repository, Extract When it Grows Principle, Dependency Inversion Principle, Clean Code and Design Patterns.
These are the backing slides of the talks given at JPoint 2017 and Devoxx PL 2017: https://www.youtube.com/embed/4-4ahz7zDiQ
Zero downtime deployment of micro-services with KubernetesWojciech Barczyński
Talk on deployment strategies with Kubernetes covering kubernetes configuration files and the actual implementation of your service in Golang and .net core.
You will find demos for recreate, rolling updates, blue-green, and canary deployments.
Source and demos, you will find on github: https://github.com/wojciech12/talk_zero_downtime_deployment_with_kubernetes
This talk introduces Spring's REST stack - Spring MVC, Spring HATEOAS, Spring Data REST, Spring Security OAuth and Spring Social - while refining an API to move higher up the Richardson maturity model
This document provides an overview of the SOLID principles of object-oriented design:
- SOLID is an acronym that stands for five design principles introduced by Robert C. Martin. The principles are Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.
- Applying these principles helps make software more maintainable, reusable, and understandable by reducing coupling between modules and increasing cohesion within modules. This addresses issues like rigidity, fragility, and immobility that make code difficult to change over time.
- The principles should be applied when refactoring existing code that shows signs of rot, such as code smells, in order to remove these
DDD Tactical Design with Clean Architecture - Ivan PaulovichIvan Paulovich
The document discusses tactical design and clean architecture. It begins with an introduction of the speaker and then defines tactical design as applying design patterns and building blocks within a bounded context to enrich the domain model in a hands-on way. It then defines clean architecture as having patterns, principles, and practices with classes and modules that follow principles of dependency inversion, stable abstractions, and stable dependencies. The rest of the document provides examples of tactical design and clean architecture concepts like entities, value objects, aggregates, and domain-driven design patterns.
The tests are trying to tell you something@VoxxedBucharest.pptxVictor Rentea
If tests are hard to write, the production design is crappy - goes an old saying. Indeed, writing unit tests gives you one of the most comprehensive, yet brutal, feedback about the design of your production code, but if it comes too late, many developers can’t stand it anymore and they will either stop testing or test more superficially. At the other extreme, others struggle to write contrived, fragile tests full of mocks that end up frustrating more than helping them. This talk reviews the main hints that unit tests provide you, from the most obvious improvements to some of the most subtle design principles.
How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features? Purely looking at unit tests is either not possible or too painful. Looking at higher-level tests can take a long time and still not give us the answers we need. For years, we have all struggled to design and structure projects that reflect the business domain.
In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing. By iteratively modifying the project structure to better model the product requirements, he has come up with a design style that helps developers create maintainable and domain-oriented software.
The domain model is an abstraction of the problem domain that your system supports. It contains the objects and operations that are crucial to your system and its users. Therefore the design of the domain model deserves the utmost care and attention. In this session you will be introduced to Domain-Driven Design and you will learn how to put Domain-Driven Design (DDD) into practice. We will explore how to apply DDD on tactical level to design a rich domain model that encapsulates behaviour, protects its invariants and can be tested in isolation from its runtime environment
This document provides an introduction to domain-driven design (DDD). It defines DDD as an approach where the application's domain model reflects the real business domain and core domain is the primary focus. It discusses DDD principles like ubiquitous language, domain encapsulation, and technical simplicity. The benefits of DDD include improved communication through a shared language, a modular and extensible domain model, and the domain rules and logic being encapsulated in one place.
Microservice With Spring Boot and Spring CloudEberhard Wolff
Spring Boot and Spring Cloud are an ideal foundation for creating Microservices based on Java. This presentation explains basic concepts of these libraries.
The document discusses Domain-Driven Design (DDD). It explains that DDD focuses on properly modeling the problem domain and using this domain model to drive the software design. This involves developing a ubiquitous language within the bounded context of the domain model and ensuring consistency between this language, the domain model, and the software code. Patterns like entity, value object, aggregate, and repository can be used, but the domain model is the most important pattern in DDD.
A introduction to Microservices Architecture: definition, characterstics, framworks, success stories. It contains a demo about implementation of microservices with Spring Boot, Spring cloud an Eureka.
The document discusses Microservices architecture and compares it to monolithic architecture. It covers topics like infrastructure for Microservices including API gateways, service discovery, event buses. It also discusses design principles like domain-driven design, event sourcing and CQRS. Microservices are presented as a better approach as they allow independent deployments, scale independently and use multiple programming languages compared to monolithic applications.
Kevin Huang: AWS San Francisco Startup Day, 9/7/17
Architecture: When, how, and if to adopt microservices - Microservices are not for everyone! If you're a small shop, a monolith provides a great amount of value and reduces the complexities involved. However as your company grows, this monolith becomes more difficult to maintain. We’ll look at how microservices allow you to easily deploy and debug atomic pieces of infrastructure which allows for increased velocity in reliable, tested, and consistent deploys. We’ll look into key metrics you can use to identify the right time to begin the transition from monolith to microservices.
- Microservices advocate creating a system from small, isolated services that each own their data and are independently scalable and resilient. They are inspired by biological cells that are small, single-purpose, and work together through messaging.
- The system is divided using a divide and conquer approach, decomposing it into discrete subsystems that communicate over well-defined protocols. Each microservice focuses on a single business capability and owns its own data and behavior.
- Microservices communicate asynchronously through APIs and events to maintain independence and isolation, which enables continuous delivery, failure resilience, and independent scaling of each service.
Domain Driven Design and Hexagonal Architecture with RailsDeclan Whelan
You know that Domain Driven Design, Hexagonal Architecture, and the Single Responsibility Principle are important but it’s hard to know how to best apply them to Rails applications. Following the path of least-resistance will get you in trouble. In this session you will learn a way out of the “fat model, skinny controller” hell. You will leave with a roadmap to guide your design based on concepts from Domain Driven Design and Hexagonal Architecture.
The document discusses Domain Driven Design (DDD), a software development approach that focuses on building an object-oriented model of the domain that software needs to represent. It emphasizes modeling the domain closely after the structure and language of the problem domain. Key aspects of DDD discussed include ubiquitous language, bounded contexts, entities, value objects, aggregate roots, repositories, specifications, domain services, modules, domain events, and command query separation. DDD is best suited for projects with a significant domain complexity where closely modeling the problem domain can help manage that complexity.
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
Distributed Transactions is a key concept for Micro Services based Apps and Saga Design Pattern helps out over here. However, developers struggle to shift their mindset from CRUD based design to Event Sourcing / CQRS concept. To solve this problem we are introducing the concept of Event Storming and Event Storming Process map.
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
Talk built based on several of my trainings: http://www.victorrentea.ro/#training
Covers: Clean/Onion/Hexagonal Architecture, Domain Entities, Value Objects, Repository, Extract When it Grows Principle, Dependency Inversion Principle, Clean Code and Design Patterns.
These are the backing slides of the talks given at JPoint 2017 and Devoxx PL 2017: https://www.youtube.com/embed/4-4ahz7zDiQ
Zero downtime deployment of micro-services with KubernetesWojciech Barczyński
Talk on deployment strategies with Kubernetes covering kubernetes configuration files and the actual implementation of your service in Golang and .net core.
You will find demos for recreate, rolling updates, blue-green, and canary deployments.
Source and demos, you will find on github: https://github.com/wojciech12/talk_zero_downtime_deployment_with_kubernetes
This talk introduces Spring's REST stack - Spring MVC, Spring HATEOAS, Spring Data REST, Spring Security OAuth and Spring Social - while refining an API to move higher up the Richardson maturity model
This document provides an overview of the SOLID principles of object-oriented design:
- SOLID is an acronym that stands for five design principles introduced by Robert C. Martin. The principles are Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.
- Applying these principles helps make software more maintainable, reusable, and understandable by reducing coupling between modules and increasing cohesion within modules. This addresses issues like rigidity, fragility, and immobility that make code difficult to change over time.
- The principles should be applied when refactoring existing code that shows signs of rot, such as code smells, in order to remove these
DDD Tactical Design with Clean Architecture - Ivan PaulovichIvan Paulovich
The document discusses tactical design and clean architecture. It begins with an introduction of the speaker and then defines tactical design as applying design patterns and building blocks within a bounded context to enrich the domain model in a hands-on way. It then defines clean architecture as having patterns, principles, and practices with classes and modules that follow principles of dependency inversion, stable abstractions, and stable dependencies. The rest of the document provides examples of tactical design and clean architecture concepts like entities, value objects, aggregates, and domain-driven design patterns.
The tests are trying to tell you something@VoxxedBucharest.pptxVictor Rentea
If tests are hard to write, the production design is crappy - goes an old saying. Indeed, writing unit tests gives you one of the most comprehensive, yet brutal, feedback about the design of your production code, but if it comes too late, many developers can’t stand it anymore and they will either stop testing or test more superficially. At the other extreme, others struggle to write contrived, fragile tests full of mocks that end up frustrating more than helping them. This talk reviews the main hints that unit tests provide you, from the most obvious improvements to some of the most subtle design principles.
How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features? Purely looking at unit tests is either not possible or too painful. Looking at higher-level tests can take a long time and still not give us the answers we need. For years, we have all struggled to design and structure projects that reflect the business domain.
In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing. By iteratively modifying the project structure to better model the product requirements, he has come up with a design style that helps developers create maintainable and domain-oriented software.
Testing is fundamental in software development. Quality gates demand high coverage levels, pull requests need sufficient tests, leading to teams spending considerable time writing and maintaining them. But are we using our tests to their full potential?
'If code is hard to test, the design can be improved'. Starting from this mantra, this deep-dive session unveils hints to simplify code, break-down complexity, and effectively use functional programming. We'll delve into topics like fixture creep, partial mocks, onion architecture, and pure functions, providing numerous best practices and practical tips for your testing.
Be warned: This session may significantly disrupt your work routine and will likely change how you see testing. Attend at your own risk.
Clean architecture - Protecting the DomainVictor Rentea
The goal of architecture is to simplify the most complex parts of your logic. Any other goal should be secondary to this. The problem is that you can’t always anticipate where the complexity of your application will accumulate, especially when confronted with ever-changing requirements. The only way to keep your code simple is to gradually evolve the architecture without adding useless complexity up front, but always looking out for opportunities to break-down and refactor towards the most simple design that solves the problem. Drawing concepts from the Domain-Driven Development mindset, this talk summarizes the most important lessons learned designing and consulting many real-world projects. Along the way, you’ll hear about Value Objects and Entities, DTOs, Dependency Inversion Principle, Facades, the Onion Architecture and many pragmatic tips and tricks immediately applicable to your day-to-day work.
1. The document discusses object-oriented programming concepts like abstraction, encapsulation, inheritance, polymorphism, and dynamic binding.
2. It then provides details on the history and features of Java, including how Java code is compiled and run on the Java Virtual Machine.
3. Core object-oriented features of Java like classes, objects, constructors, and method overloading are explained.
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024Victor Rentea
The microservices honeymoon is over. When starting a new project or revamping a legacy monolith, teams started looking for alternatives to microservices. The Modular Monolith, or 'Modulith', is an architecture that reaps the benefits of (vertical) functional decoupling without the high costs associated with separate deployments. This talk will delve into the advantages and challenges of this progressive architecture, beginning with exploring the concept of a 'module', its internal structure, public API, and inter-module communication patterns. Supported by spring-modulith, the talk provides practical guidance on addressing the main challenges of a Modultith Architecture: finding and guarding module boundaries, data decoupling, and integration module-testing. You should not miss this talk if you are a software architect or tech lead seeking practical, scalable solutions.
About the author
With two decades of experience, Victor is a Java Champion working as a trainer for top companies in Europe. Five thousands developers in 120 companies attended his workshops, so he gets to debate every week the challenges that various projects struggle with. In return, Victor summarizes key points from these workshops in conference talks and online meetups for the European Software Crafters, the world’s largest developer community around architecture, refactoring, and testing. Discover how Victor can help you on victorrentea.ro : company training catalog, consultancy and YouTube playlists.
Tampere Docker meetup - Happy 5th Birthday DockerSakari Hoisko
Part of official docker meetup events by Docker Inc.
https://events.docker.com/events/docker-bday-5/
Meetup event:
https://www.meetup.com/Docker-Tampere/events/248566945/
Montreal Kubernetes Meetup: Developer-first workflows (for microservices) on ...Ambassador Labs
1. The document discusses developer-first workflows for building and operating microservices on Kubernetes.
2. It recommends creating self-sufficient, autonomous teams and using Kubernetes, Docker, and Envoy to provide the basic infrastructure primitives needed for distributed workflows.
3. The strategies suggested depend on the service maturity level and include using similar development and production environments for prototyping, implementing software redundancy for production services, and defining service level objectives and network observability for internal dependencies.
(IMPROVED VERSION FROM GEECON)
How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features? Purely looking at unit tests is either not possible or too painful. Looking at higher-level tests can take a long time and still not give us the answers we need. For years, we have all struggled to design and structure projects that reflect the business domain.
In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing. By iteratively modifying the project structure to better model the application requirements, he has come up with a design style that helps developers create maintainable and domain-oriented software.
Presentation from RedDotRubyConf 2011 in Singapore. It explains multi-tenancy and why it is increasingly required for Rails development. Four of the many approaches are covered in some detail (including what resources we have available for re-use) and I end with a naive question (& call to action?) .. "Isn't it about time there was a 'Rails Way'?"
This document introduces Interaction-Driven Design (IDD) and discusses best practices for application structure and testing strategies when using this approach. It recommends starting the design process from the user interactions or actions needed, which will help define domain concepts and emerging entities. The core domain model should be separated from infrastructure implementations. Testing strategies covered include user journey tests at the application level, acceptance tests at the action level, integration tests at boundaries, and unit tests at the class level. Dependencies should be mocked or stubbed at different test levels.
DDD, CQRS and testing with ASP.Net MVCAndy Butland
This document provides an overview of a presentation on Domain Driven Design (DDD), Command Query Responsibility Segregation (CQRS), and testing with ASP.Net MVC. It introduces the presenter and gives an outline of the topics to be covered, including implementing DDD with ASP.Net MVC and Entity Framework, using a mediator pattern for CQRS, and unit testing models, queries, and commands. References are given to other authors and resources that influenced the approaches and implementations discussed in the presentation.
The document provides recipes for building CQRS architectures. It begins with an introduction and agenda. Lesson 1 discusses a basic layered architecture, noting its limitations in scalability and evolvability. Lesson 2 introduces n-layered architecture with dependency injection to improve decoupling but it also has scalability issues. Lesson 3 explains the Command Query Responsibility Segregation (CQRS) pattern, separating read and write operations for improved scalability and flexibility. It provides code examples of implementing CQRS. The document aims to help architects evolve monolithic systems to more scalable and maintainable architectures.
Avoiding the domino effect in our [micro]services (SOLID at macro-design level)CodelyTV
How can we apply SOLID principles to a macro-design level in our [micro]services architectures?
In this talk we will see a problem-solution approach on how we deal with different kinds of load for our different services in order to avoid a domino effect while having peaks of request in one of our services. We'll do so using Domain Events and Message Queues such as RabbitMQ and AWS SNS-SQS.
Spanish resources:
* Hexagonal Architecture course: https://pro.codely.tv/library/arquitectura-hexagonal/66748/about/
* CQRS course: https://pro.codely.tv/library/cqrs-command-query-responsibility-segregation-3719e4aa/62554/about/
* HTTP API with Scala course: https://pro.codely.tv/library/api-http-con-scala-y-akka/66747/about/
* Testing in CQRS architectures talk: https://www.youtube.com/watch?v=cw6Va1ZW7iI
* We broke up with the monolith, and started dating event sourcing slides: https://www.slideshare.net/JavierCane/we-broke-up-with-the-monolith-and-started-dating-eventsourcing-symfonycat
English resources:
* The anatomy of Domain Event: blog.arkency.com/2016/05/the-anatomy-of-domain-event/
* Versioning in an Event Sourced System book: https://leanpub.com/esversioning
* RabbitMQ Simulator: tryrabbitmq.com
* A Series of Fortunate Events slides: https://www.slideshare.net/matthiasnoback/a-series-of-fortunate-events-symfony-camp-sweden-2014
Elements of DDD with ASP.NET MVC & Entity Framework Code First v2Enea Gabriel
The document discusses Domain-Driven Design (DDD) with ASP.NET MVC and Entity Framework Code First. It covers challenges with traditional architecture like layers coupling and where to implement business rules. DDD is presented as a new default architecture where the database is not the primary focus, layers are loosely coupled, and business rules are within the application domain. Today's tools like ASP.NET MVC, dependency injection frameworks, and Entity Framework Code First are discussed. A demo is presented and conclusions recommend focusing on analyzing dependencies, designing the domain, and doing refactoring and unit testing.
IBM Think Session 8598 Domino and JavaScript Development MasterClassPaul Withers
Session from IBM Think 2018. Note: the architecture used is an extreme case of what's possible (and it could go further), rather than a real-world expectation
Inria Tech Talk : Comment améliorer la qualité de vos logiciels avec STAMPStéphanie Roger
Que vous soyez développeur ou entrepreneur, découvrez le projet STAMP piloté par Inria, l'institut national de recherche dédié aux sciences du numérique.
Reactive programming allows for non-blocking and concurrent executions. It is designed to be more efficient by using fewer threads and less memory. This makes applications more resilient and scalable to handle high connection volumes and traffic variability. The developer experience is improved through actionable stacktraces and debugging of reactive flows.
Since the introduction of replication in MySQL, users have been trying to automate the promotion of a replica to a primary as well as automating the failover of TCP connections from one database server to another in the event of a database failure: planned or unplanned. For over a decade, users and organizations have designed various types of solutions to achieve this. Though, many of these solutions were done manually or were using third party software, mostly open source, to automate and integrate various architectures.
For more than 5 years now, MySQL offers complete and very easy-to-use solutions to set up database architectures that provide High-Availability and recently added Disaster Recovery capabilities. Completely built in-house and supported by Oracle, many enterprises large and small have adopted these solutions into business-critical applications.
Business requirements dictate what type of database architecture is required for your system. Disaster tolerance is key and can be measured at different levels: data loss, data availability, and uptime. In this session, the various MySQL Database Architecture solutions will be covered to help you choose the right solution based on your business requirements
Tracing the root cause of a performance issue requires a lot of patience, experience, and focus. It’s so hard that we sometimes attempt to guess by trying out tentative fixes, but that usually results in frustration, messy code, and a considerable waste of time and money. This talk explains how to correctly zoom in on a performance bottleneck using three levels of profiling: distributed tracing, metrics, and method profiling. After we learn to read the JVM profiler output as a flame graph, we explore a series of bottlenecks typical for backend systems, like connection/thread pool starvation, invisible aspects, blocking code, hot CPU methods, lock contention, and Virtual Thread pinning, and we learn to trace them even if they occur in library code you are not familiar with. Attend this talk and prepare for the performance issues that will eventually hit any successful system.
About authorWith two decades of experience, Victor is a Java Champion working as a trainer for top companies in Europe. Five thousands developers in 120 companies attended his workshops, so he gets to debate every week the challenges that various projects struggle with. In return, Victor summarizes key points from these workshops in conference talks and online meetups for the European Software Crafters, the world’s largest developer community around architecture, refactoring, and testing. Discover how Victor can help you on victorrentea.ro : company training catalog, consultancy and YouTube playlists.
The network is reliable, has zero latency, with infinite, free bandwidth... And then you wake up. The plan was to go to microservices to build those reliable, super-scalable systems you saw in the ad. But your systems only communicate over synchronous protocols and the team never had a serious discussion about timeouts, retries, circuit breakers, and bulkhead patterns. If that’s your crude reality, please attend this session!
One of the many challenges of a distributed architecture is preserving the consistency of data across different systems. During this one-hour presentation, we are going to explore a number of strategies for maintaining consistency, going from the most basic options up to an automated recovery mechanism using compensations and reservations - what’s commonly referred to as a “saga” pattern. Our journey will be based on a hypothetical food delivery application on which we will analyze various decisions and their tradeoffs. The discussion will stay at an abstract, architectural level for the most part, with only a few code examples.
In the agenda:
- Idempotency and Retries
- 2 Phase Commit
- Eventual Consistency
- Compensations
- Reservations
- The Saga Pattern
Clean Code @Voxxed Days Cluj 2023 - opening KeynoteVictor Rentea
Clean Code principles have become a cornerstone of professional developer teams worldwide. But frameworks and languages have evolved, and so have the challenges we’re facing today while crafting modern applications. Single-page apps, extremely DRY code, microservices, excessive functional programming, and reactive flows have all taken their toll on our code quality. Hop aboard this roundtrip of the most damaging Code Smells as of 2023 and fill your toolbox with a load of practical tricks you can immediately apply to your day-to-day work. All in an entertaining show spiced with live-coding moments.
Testing strategies for modern software architectures are evolving. As we transition from monolithic structures to team-sized microservices with crisp APIs aligned to bounded contexts, we encounter more stable testing surfaces. This shift leads many high-performing teams to favor integration tests over fine-grained, brittle unit tests. These integration tests, which are closer to the functional requirements, prove more trustworthy and are more resilient to internal refactoring, though they may come with a higher cost. In a vivid and engaging style, this talk addresses the primary challenges of integration testing in the microservices era: cognitive overload, test isolation, and test execution speed. Join the testing revolution and discover how to enhance your team's testing efficiency and effectiveness.
Ready for a deep dive into the world's most challenging programming paradigm? Reactive programming can simplify asynchronous and event-driven applications, but without a strong understanding, it can lead to frustration, recurring patchwork, missed deadlines, and costly bugs.
In this intensive three-hour session, we'll transition a traditional Spring application to WebFlux, revealing patterns and aanti-patterns when working with repositories, REST APIs, queues, and legacy libraries. You'll gain a clear understanding of often overlooked but critical aspects like subscribe signal, errors, cancellation, and signal loss. As a bonus, we'll debate the future of Reactive vs Virtual Threads, production-ready in Java 21.
This session is crucial for developers already working with reactive programming or those intending to make the leap.
The biggest challenge in performance tuning is identifying the root cause of the bottleneck. Once you find it, the fix often becomes trivial. However, this detective work takes patience, skills, and effort, so we often attempt to guess the cause, by trying out tentative fixes. The result: messy code, waste of time and money, and frustration. During this talk you will learn how to correctly zoom in on the bottleneck using three levels of profiling: distributed tracing with Zipkin, metrics with Micrometer, and profiling with the Java Flight Recorder already built into your JVM. We’ll focus on the latter and learn how to read a flame graph to trace some common issues of backend systems like connection/thread pool starvation, time-consuming aspects, hot methods, and lock contention, even if these occur in library code you did not write.
Slides for my presentation about OAuth, going in depth in the details of the Authorization Code Grant and PKCE, also describing several security threats to OAuth
Software Craftsmanship @Code Camp Festival 2022.pdfVictor Rentea
Decades ago, IT started as a single engineering practice, but over the years it grew increasingly fragmented. The overspecialization we face today, in the context of a management-first agile transformation leads to a lack of responsibility, blaming games, repeated patching, painful communication overhead, and fulminating costs. The software craftsmanship movement is rising in this post-agile world with professionals that take control of their careers and continuously learn in the pursuit of mastery. But changing mindset requires determined team efforts and communities, especially when working remotely. What techniques and tricks can you use to grow such a culture of learning in your team? Find out from the founder and lead of one of the largest software craftsmanship communities in the world.
This talk is about technical culture and attitude.
Tests are hard to write if the production design is crappy - goes an old saying. Indeed, writing unit tests gives you one of the most comprehensive, yet brutal, feedback about the design of your production code, but if it comes too late, many developers can’t take it and they will either stop testing or test superficially. At the other end, others struggle to write contrieved, fragile tests full of mocks that end up frustrating more than helping them. This talk reviews the main hints that unit tests provide you, from the most obvious improvements to some of the most subtle design principles.
Decades ago, IT started as a single engineering practice, but as time passed by it got increasingly fragmented. Conflicts broke out between testers vs developers vs sysadmins vs DBAs vs many other roles. Recently, developers themselves split into many subspecialties like backend/frontend/iOS/Android/microservices/functions/etc. The overspecialization we face today causes huge communication overhead, a low bus factor, lack of responsibility, blaming, repeated isolated patching and fulminating costs. The software craftsmanship movement is rising in this post-agile world with professionals eager to take control of their careers and continuously learn in the pursuit of mastery. This talk will show you practical ways in which to seed a continuous learning culture in your team or company, and foster the enthusiasm of your developers.
Refactoring blockers and code smells @jNation 2021Victor Rentea
The only way to survive in a codebase is by refactoring continuously. We know that since the Extreme Programming days. But what stops us from doing so today? In this talk, Victor summarizes what he learned discussing Clean Code and Refactoring with hundreds of teams throughout the world. You'll find ideas to tackle a broad spectrum of factors: technical, cultural, psychological, emotional, social, and even political. Using these you might unlock the freedom to refactor for you and your colleagues.
After this roundtrip, the talk briefly overviews several of the most dangerous code smells in the projects today: God Class, Duplicated Code vs Divergent Code, Temporal Coupling, Middle Man, Speculative Generality, Mutable Long-Lived State, Comments, and more. For each of them we’ll discuss a typical workaround, plus several subtleties and variations.
Hibernate and Spring - Unleash the MagicVictor Rentea
This document provides an overview of several Java technologies:
- JPA Auditing for tracking entity creation/modification dates and users
- Domain Events in DDD for triggering processing across aggregates
- javax.validation for validating entities before database writes
- Spring Data Repos for implementing repositories with query methods and custom logic
It also briefly discusses JPA auditing implementation, domain event publishing, custom validators, and the @NonNullApi annotation for preventing null returns from repositories.
Integration testing with spring @JAX MainzVictor Rentea
Our sleep is better with longer-scoped tests. Our life is brighter if we don’t rely heavily on fine-grained tests that break whenever we refactor even the smallest detail. I’m talking about tilting the balance towards more integration than unit testing. And for that, let’s look at the testing features offered by the most used Java Framework today. We’ll see how to write fake test implementations, how to mock an unwanted Spring bean, what a Transactional Test is, and if and how to test your web endpoints. Along the way, we’ll also see Flaky tests, and discuss best practices about integration testing – all in an entertaining live coding session.
Your takeaways from this talk will be a lot of good practices and techniques directly applicable to your day-to-day project.
The Proxy Fairy and the Magic of Spring @JAX Mainz 2021Victor Rentea
You can only claim you know Spring if you fully understand the Proxy design pattern and how the framework uses it to do its magic. Join this live coding session to explore 6 ways of intercepting method calls that you can use to cast your own spells and dramatically simplify your codebase.
Grab a strong coffee and prepare yourself for a whirlwind of **live-coding**, interwoven with **deep theoretical concepts and implementation details** that you need to master if you are using the Spring Framework. We’ll start from a Decorator pattern implementation, proving 2 ways to wire it with Spring, then move to bare-hands interface proxies, concrete classes proxies, @Aspect applied to custom annotations, plus some standard off-the-shelf Spring aspects.
Join this talk and learn real-world best practices to use with Aspects, design hints, under-the-hood implementation details, debugging tips, and performance impact of aspects. All in an interactive, entertaining, and extremely dynamic session.
Integration testing with spring @snow oneVictor Rentea
This document provides an overview of integration testing strategies and techniques. It discusses the differences between unit tests and integration tests, including that integration tests involve multiple layers and dependencies like databases, files, and web services, making them slower and more fragile. It also covers best practices for integration tests such as using an in-memory database, WireMock for stubbing external services, transaction management, and strategies for cleaning up after tests.
Pure functions and immutable objects @dev nexus 2021Victor Rentea
aaaaThis presentation focuses on two of the most advanced design tools in your toolbox, whatever the language or framework you might be using. After understanding the basics, we'll see how these concepts can be used in real-world scenarios to simplify those several most complex use-cases in your application. At the end of a mix of slides and live-coding, you'll finally understand the power of these ideas and become prepared to apply them in your day-to-day work.
Along the way, we'll introduce concepts like Side Effects, Idempotency, Referential Transparency, Pure Functions and Deep/Shallow Immutability. Also, we'll talk about the powerful Functional Code / Imperative Shell architecture that you can use for your complex workflows.
Prepare for an entertaining, highly interactive session that will answer all your questions.
Written in Java and spoken in English.
This document describes Victor Rentea, an independent trainer and founder of the Bucharest Software Craftsmanship Community who has provided technical training to over 2000 developers over 8 years. It promotes Victor Rentea's training services on topics like Hibernate, Spring, Java performance, reactive programming, design patterns, clean code, refactoring, and unit testing in any language. The document also provides brief summaries of test-driven development and the three rules of TDD according to Uncle Bob, as well as a definition of code golf.
Definitive Guide to Working With Exceptions in Java - takj at Java Champions ...Victor Rentea
A Pragmatic approach to work with exceptions in Java. Talk recording: https://www.youtube.com/watch?v=LRwCE7GreSM&feature=youtu.be
Discussing checked exceptions, Vavr, Lombok, and JooL library, Spring Framework and many more.
Supporting in-depth article series: https://victorrentea.ro/blog/exception-handling-guide-in-java/
Don't Be Mocked by your Mocks - Best Practices using MocksVictor Rentea
Do you ❤️ Mocks? When you write your first unit tests, especially on older codebases, mocking foreign code is key to survival. But as you grow older in the craft, you start piling up hours and days wasted to refactor fragile tests or to fix bugs that those heavy mock-based tests didn't catch. And so you start looking at Mocks differently.
Let's go through the key factors to consider to strike the optimal balance between what needs to be mocked away and what code should be tested in integration. There's sometimes a fine line there, often interwoven with strong emotions:
"Why am I testing this?"
"Argh… these tests take too long"
"Can this ever really break?"
etc...
Among the points that we'll touch on:
- Mocks vs Refactoring
- Mocks vs Reliability
- Fine vs Coarse Mocks
- Reproducibility
- Partial Mocks
- Mocking Statics
- Alternatives to Mocks
Speakers: Victor Rentea
Victor is a Java Champion and Independent Trainer with an impressive experience: thousands of developers in dozens of companies trained in dedicated company sessions. He is the founder of one of the largest developer communities in Romania, Bucharest Software Craftsmanship Community and a top international conference speaker.
To find more about him, join a live masterclass or call him in for a company dedicated training: victorrentea.ro
The Role of DevOps in Digital Transformation.pdfmohitd6
DevOps plays a crucial role in driving digital transformation by fostering a collaborative culture between development and operations teams. This approach enhances the speed and efficiency of software delivery, ensuring quicker deployment of new features and updates. DevOps practices like continuous integration and continuous delivery (CI/CD) streamline workflows, reduce manual errors, and increase the overall reliability of software systems. By leveraging automation and monitoring tools, organizations can improve system stability, enhance customer experiences, and maintain a competitive edge. Ultimately, DevOps is pivotal in enabling businesses to innovate rapidly, respond to market changes, and achieve their digital transformation goals.
DECODING JAVA THREAD DUMPS: MASTER THE ART OF ANALYSISTier1 app
Are you ready to unlock the secrets hidden within Java thread dumps? Join us for a hands-on session where we'll delve into effective troubleshooting patterns to swiftly identify the root causes of production problems. Discover the right tools, techniques, and best practices while exploring *real-world case studies of major outages* in Fortune 500 enterprises. Engage in interactive lab exercises where you'll have the opportunity to troubleshoot thread dumps and uncover performance issues firsthand. Join us and become a master of Java thread dump analysis!
Boost Your Savings with These Money Management AppsJhone kinadey
A money management app can transform your financial life by tracking expenses, creating budgets, and setting financial goals. These apps offer features like real-time expense tracking, bill reminders, and personalized insights to help you save and manage money effectively. With a user-friendly interface, they simplify financial planning, making it easier to stay on top of your finances and achieve long-term financial stability.
WMF 2024 - Unlocking the Future of Data Powering Next-Gen AI with Vector Data...Luigi Fugaro
Vector databases are transforming how we handle data, allowing us to search through text, images, and audio by converting them into vectors. Today, we'll dive into the basics of this exciting technology and discuss its potential to revolutionize our next-generation AI applications. We'll examine typical uses for these databases and the essential tools
developers need. Plus, we'll zoom in on the advanced capabilities of vector search and semantic caching in Java, showcasing these through a live demo with Redis libraries. Get ready to see how these powerful tools can change the game!
Transforming Product Development using OnePlan To Boost Efficiency and Innova...OnePlan Solutions
Ready to overcome challenges and drive innovation in your organization? Join us in our upcoming webinar where we discuss how to combat resource limitations, scope creep, and the difficulties of aligning your projects with strategic goals. Discover how OnePlan can revolutionize your product development processes, helping your team to innovate faster, manage resources more effectively, and deliver exceptional results.
Why Apache Kafka Clusters Are Like Galaxies (And Other Cosmic Kafka Quandarie...Paul Brebner
Closing talk for the Performance Engineering track at Community Over Code EU (Bratislava, Slovakia, June 5 2024) https://eu.communityovercode.org/sessions/2024/why-apache-kafka-clusters-are-like-galaxies-and-other-cosmic-kafka-quandaries-explored/ Instaclustr (now part of NetApp) manages 100s of Apache Kafka clusters of many different sizes, for a variety of use cases and customers. For the last 7 years I’ve been focused outwardly on exploring Kafka application development challenges, but recently I decided to look inward and see what I could discover about the performance, scalability and resource characteristics of the Kafka clusters themselves. Using a suite of Performance Engineering techniques, I will reveal some surprising discoveries about cosmic Kafka mysteries in our data centres, related to: cluster sizes and distribution (using Zipf’s Law), horizontal vs. vertical scalability, and predicting Kafka performance using metrics, modelling and regression techniques. These insights are relevant to Kafka developers and operators.
Baha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdfBaha Majid
IBM watsonx Code Assistant for Z, our latest Generative AI-assisted mainframe application modernization solution. Mainframe (IBM Z) application modernization is a topic that every mainframe client is addressing to various degrees today, driven largely from digital transformation. With generative AI comes the opportunity to reimagine the mainframe application modernization experience. Infusing generative AI will enable speed and trust, help de-risk, and lower total costs associated with heavy-lifting application modernization initiatives. This document provides an overview of the IBM watsonx Code Assistant for Z which uses the power of generative AI to make it easier for developers to selectively modernize COBOL business services while maintaining mainframe qualities of service.
WWDC 2024 Keynote Review: For CocoaCoders AustinPatrick Weigel
Overview of WWDC 2024 Keynote Address.
Covers: Apple Intelligence, iOS18, macOS Sequoia, iPadOS, watchOS, visionOS, and Apple TV+.
Understandable dialogue on Apple TV+
On-device app controlling AI.
Access to ChatGPT with a guest appearance by Chief Data Thief Sam Altman!
App Locking! iPhone Mirroring! And a Calculator!!
A Comprehensive Guide on Implementing Real-World Mobile Testing Strategies fo...kalichargn70th171
In today's fiercely competitive mobile app market, the role of the QA team is pivotal for continuous improvement and sustained success. Effective testing strategies are essential to navigate the challenges confidently and precisely. Ensuring the perfection of mobile apps before they reach end-users requires thoughtful decisions in the testing plan.
Alluxio Webinar | 10x Faster Trino Queries on Your Data PlatformAlluxio, Inc.
Alluxio Webinar
June. 18, 2024
For more Alluxio Events: https://www.alluxio.io/events/
Speaker:
- Jianjian Xie (Staff Software Engineer, Alluxio)
As Trino users increasingly rely on cloud object storage for retrieving data, speed and cloud cost have become major challenges. The separation of compute and storage creates latency challenges when querying datasets; scanning data between storage and compute tiers becomes I/O bound. On the other hand, cloud API costs related to GET/LIST operations and cross-region data transfer add up quickly.
The newly introduced Trino file system cache by Alluxio aims to overcome the above challenges. In this session, Jianjian will dive into Trino data caching strategies, the latest test results, and discuss the multi-level caching architecture. This architecture makes Trino 10x faster for data lakes of any scale, from GB to EB.
What you will learn:
- Challenges relating to the speed and costs of running Trino in the cloud
- The new Trino file system cache feature overview, including the latest development status and test results
- A multi-level cache framework for maximized speed, including Trino file system cache and Alluxio distributed cache
- Real-world cases, including a large online payment firm and a top ridesharing company
- The future roadmap of Trino file system cache and Trino-Alluxio integration
How Can Hiring A Mobile App Development Company Help Your Business Grow?ToXSL Technologies
ToXSL Technologies is an award-winning Mobile App Development Company in Dubai that helps businesses reshape their digital possibilities with custom app services. As a top app development company in Dubai, we offer highly engaging iOS & Android app solutions. https://rb.gy/necdnt
Building API data products on top of your real-time data infrastructureconfluent
This talk and live demonstration will examine how Confluent and Gravitee.io integrate to unlock value from streaming data through API products.
You will learn how data owners and API providers can document, secure data products on top of Confluent brokers, including schema validation, topic routing and message filtering.
You will also see how data and API consumers can discover and subscribe to products in a developer portal, as well as how they can integrate with Confluent topics through protocols like REST, Websockets, Server-sent Events and Webhooks.
Whether you want to monetize your real-time data, enable new integrations with partners, or provide self-service access to topics through various protocols, this webinar is for you!
Mobile App Development Company In Noida | Drona InfotechDrona Infotech
React.js, a JavaScript library developed by Facebook, has gained immense popularity for building user interfaces, especially for single-page applications. Over the years, React has evolved and expanded its capabilities, becoming a preferred choice for mobile app development. This article will explore why React.js is an excellent choice for the Best Mobile App development company in Noida.
Visit Us For Information: https://www.linkedin.com/pulse/what-makes-reactjs-stand-out-mobile-app-development-rajesh-rai-pihvf/
4. 4 VictorRentea.ro
a training by
Chapter 1. Concentric Architectures
= Onion, Clean, Hexagonal, Ports-and-Adapters
5. 5 VictorRentea.ro
a training by
IAdapter
Adapter
Onion/Clean Architecture Recap
Outer layers depend on inner layers
Persistence concerns pushed out
Dependency Inversion
(call logic in an outer circle via an interface)
Services + Model
Flow control
(method call direction)
Domain is agnostic to
UI, DB, APIs, Frameworks
(protect the business rules)
Onion Architecture Primer: https://marcoatschaefer.medium.com/onion-architecture-explained-building-maintainable-software-54996ff8e464
7. 7 VictorRentea.ro
a training by
vs interface
Hexagonal aka Port-and-Adapters Architecture
Original Article: https://alistair.cockburn.us/hexagonal-architecture/
Bad cost-benefit
Useless
interface
implements
DepENDENCY INvERSION
Flow control
(method call direction)
8. 9 VictorRentea.ro
a training by
https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/
9. 10 VictorRentea.ro
a training by
Sources of overengineering in Concentric Architectures
Too many interfaces
"any layer must only expose and consume interfaces"
Mandated layers
"a Controller MUST call a Service that MUST call a Repo"
Mock-full tests 🧅
"each layer is tested by mocking the layer below"
Separate Domain from Persistence 😭
"CustomerModel should be mapped CustomerEntity in Repo layer"
Application-layer structures
"Application layer should have its own data structures ≠Domain, ≠Dto"
Rigid dependency management
"domain MUST NEVER depend on anything outside"
Monolithic in nature
"the (one) Domain is in the center"
Are these still problems
in our pragmatic variation?
Delete interfaces with only 1 implementation, unless Dep Inversion
Extract complexity into Domain Services; challenge Controllers
More integration tests (honeycomb) or squash layers
ArchUnit allows exceptions 😬
Only required if UC exposed via 2+ channels
Gulp... 😬 Indeed
Only required if legacy/enemy DB
11. 12 VictorRentea.ro
a training by
Layers
Controller
Repository + Infrastructure
Application Service
Vertical SLICING
DOMAIN Service + Model
Change
12. 13 VictorRentea.ro
a training by
How "wide" should an Application Service be?
= how many use-cases?
Multiple use-cases 👈 what we did
class OrderApplicationService {
public getOrderById() {/*trivial logic🥱*/}
public placeOrder() {..extract..extract...}
// eg. 10 more
}
One class / use-case = Slice by Feature
class GetOrderByIdUseCase{/* 5 useful lines*/}
class PlaceOrderUseCase {/* 400 lines */}
risk: god class
https://jimmybogard.com/vertical-slice-architecture/
continuously extract logic ou
accidental coupling
between use-cases
change 1 use-case=
change 1 (less) files
Group code
by axis of change
13. 14 VictorRentea.ro
a training by
One class / use-case = Slice by Feature
class GetOrderByIdUseCase{/* 5 useful lines*/}
class PlaceOrderUseCase {/* 400 lines */} risk: god classes
https://jimmybogard.com/vertical-slice-architecture/
The stricter the rules are,
the less creative we think
risk: too small classes
risk: repeating logic (DR
extract shared logic to Domain
extract complex logic to Domain
Start Put everything related to a UseCase in a single file,
from Controller down to any custom Repository methods
14. 15 VictorRentea.ro
a training by
One class / use-case = Slice by Feature
class GetOrderByIdUseCase{/* 5 useful lines*/}
class PlaceOrderUseCase {/* 400 lines */}
Query
Command
read data
change data
CQRS
15. 16 VictorRentea.ro
a training by
Encapsulate DTOs
whenever possible
class GetOrderByIdUseCase{ // query 👁
private static class Request { ... } // JSON
private static class Response { ... } // JSON
public Response handle(Request request) {...}
}
class PlaceOrderUseCase { // command ✍️
private static class Request { ... } // JSON
private static class Response { ... } // JSON
public Response handle(Request request) {...}
}
allows different architecture styles per use-case
16. 17 VictorRentea.ro
a training by
Queries 👁
class GetOrderById {
private static class Request { ... }
private static class Response { ....<large>...... }
@GetMapping
public Response handle(Request request) {...}
}
- Can select projections ("select new Dto" JPQL) = different READ Model (CQRS)
- Can use raw SQL, or whatever ...
- If ≥2 Query UC share logic (rarely) extract it (eg. into a Util) = DRY
17. 18 VictorRentea.ro
a training by
Commands ✍️
• Start simple
• Can get veeeery complex. Don't PANIC! Continuously refactor:
Extract Method
Extract Class
Move Methods (into a Domain Model Object or a Domain Service)
class PlaceOrder {
private static class Request { ....<large>.... } // + @NotNull, @Size..
private static class Response { ... }
@PostMapping
@Transactional
public Response handle(@Validated Request request) {
*read stuff*
*interesting domain logic to extract*
*save stuff*
}
}
Perfect Fit for
Task-Based UI
18. 19 VictorRentea.ro
a training by
Layers
Controller
Repository + Infrastructure
Application Service
SLICE BY FEATURE
DOMAIN Service/Model
Logic Shared by 2 Features
extracted into a Domain Service/Model
Complex business logic of a Feature
extracted into a Domain Service/Model
19. 20 VictorRentea.ro
a training by
Application / Infrastructure
Domain
👁 UC-1
External API
✍️UC-3 ✍️UC-4
Domain
Service
Vertical-Slicing vs Concentric Architecture Equivalence
✍️UC-2
Domain
Model
👁 UC-19
👁 UC-17
Not enough domain complexity:
they don't deserve
to be part of Domain
20. 21 VictorRentea.ro
a training by
Microservice (if you must)
Module in a Modulith 👑
Large Slice
Shippin
g
Invoicin
g
Catalo
g
NO: Each Module can decide
how many layers/rings has
its internal structure
Slice by Feature
(aka UseCase, previous slides)
Vertical Slicing Small Slice
What
Size?
No
layers?
= Modular Monolith
21. 22 VictorRentea.ro
a training by
A large codebase is more likely to suffer
from internal coupling (scope creep, domain model dilution),
than external coupling (to external APIs)
24. 25 VictorRentea.ro
a training by
.controller
.service
.repo
.infra
com.myorg.myapp
.order
.product
Too keep packages small,
we grouped classes
in subpackages
Package Names
.entity
.order
.product
ll started with...
technical layers names
(not domain concepts)
25. 26 VictorRentea.ro
a training by
.service
com.myorg.myapp .order
.product .service
The Screaming Architecture
=organize code first by subdomain, not by technical layers
https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
.entity
.repo
…
…
separate microservices
teams
modules
26. 27 VictorRentea.ro
a training by
Naming
(again)
.order .product
.fulfillment .catalog
.invoice
.invoicing
Group by Business Capability👌
(what it does, its value)
Group by Concept (Data)
28. 29 VictorRentea.ro
a training by
The Fallacy of Nano-Services
• If you break the code in too many modules (eg 20+)
• The local complexity of each piece is ↓ ✅
• But the global complexity gets 🔝 🚫🚫🚫
or Module
https://vladikk.com/2020/04/09/untangling-microservices/
29. 30 VictorRentea.ro
a training by
The Fallacy of Nano-Services
or Module
Local Complexity
how much complexity is
in one microservice/module
Global Complexity
how hard it is to integrate
the microservices/modules
Increase cohesiveness of modules (=break complexity)
while reducing coupling between them (=micro-APIs)
https://vladikk.com/2020/04/09/untangling-microservices/
30. 31 VictorRentea.ro
a training by
A Service is NOT
• Just behavior
Example: calculation, validation
• Just CRUD data
Example: Country, Tenant, Clinic
or Module
Modulith: repos in commons
Microservices: static data or
entity microservice
31. 32 VictorRentea.ro
a training by
A Service is ...
the technical authority for a business capability
or Module
.invoice .invoicing
32. 33 VictorRentea.ro
a training by
Cognitive🧅 Load: able to specialize in one area
Code Ownership & Control: free to refactor the Domain Model
Bounded Contexts: sharp concepts, less attributes & more constraints
Ideally 1 module = 1 Team = Two-Pizza Team
Align with Organization Boundaries (stakeholders) - Conway's Law
Has a sound responsibility ?
Finding Module Boundaries🏆
Changing its internal structures and business rules affects other modules?
Its API changes when other modules change? (=coupling)
Is it replaceable with off-the-shelf software?
Is it easy to remove when the business need is gone?
Is it testable alone, ie without creating many entities from other modules?
36. 40 VictorRentea.ro
a training by
What's faster to build?
(from scratch)
Microservices
A Monolith or
But soon complexity and
coupling
start slowing us down
37. 41 VictorRentea.ro
a training by
41
From a Big Ball of Mud Microservices
1) Rewrite (big-bang)
No new features for 1 year
Requires re-specifying everything
20-30% success chance (studies)
2) Modularize => Extract
Experiment and prototype
Be ready to stop any time
3) Strangler-Fig Pattern
Reimplement any all features
in fresh microservices
👑
Modulith
38. 42 VictorRentea.ro
a training by
A new greenfield project
Proxy
The Strangler Fig Pattern
😁
When a feature is
reimplemented,
route the requests for it
to the new project
Prerequisite: clear requirements
39. 43 VictorRentea.ro
a training by
order
product
Unlink Domain Entities
class OrderLine {
...
Product product;
Long productId;1
String productName;2
}
class Product {
id
name
...
}
1) Keep only the ID ✅
👌 Preserve the FK in Modulith
+ then later: fetch on-demand
2) Snapshot immutable data
+ according to domain rules
3) Keep mutable data in sync 😨
+ replicate changes (eg via events)
⚠️Eventual Consistency (iff distributed)
object
reference
40. 44 VictorRentea.ro
a training by
complexity
complexity
booking appointment
Split Domain Entities
class BookingRequest {
id
date + time
specialtyId
...
}
class Appointment {
id
medical report
followup date
date + time
...
}
class Appointment {
id
date + time
specialtyId
... +20 fields
appointed:boolean
medical report
followup date
... 40 more
}
41. 45 VictorRentea.ro
a training by
👌
The owner of some data
is the module who changes it
The modules that need the data must ask the owner
42. 46 VictorRentea.ro
a training by
0 Writers | * Readers = Reference Data 'shared' module
- eg. Country list
1 Writer | n Readers = Owned Readers get data from Writer
- eg. Catalog Stock.getStock()
n Writers | 0 Readers = Notifications commons via events
- eg. Audit, sendSMS
2+ Writers | * Readers Split Entity 😩 or Merge modules ❤️
- eg. break Order PlacedOrder + ShippedOrder
Data Ownership
# modules
43. 48 VictorRentea.ro
a training by
Calls between Modules
module
A
module
B
call any class inside B
Lack of
encapsulation
External API
(eg HTTP, gRPC,...)
dev riot
Why so many
structures?!!😡
Goal = Decoupling
- Review the coupling
- Detect cyclic dependencies
- Detect "Module in the middle"
DTO
Internal API
("Door")
DDO
Data Decoupling Objects
calls only via B's "Door"
44. 49 VictorRentea.ro
a training by
Cyclic Dependencies between Modules
A B
call
call
Bad news: Maven/Gradle build fails
<dependency>
<dependency>
45. 50 VictorRentea.ro
a training by
Ways to fix Cyclic Dependencies between Modules
Key Questions:
- massive interdependence?
- need to reuse technical/infra stuff?
- any existing monolithical clients / frozen API?
- are modules exposing external APIs?
46. 51 VictorRentea.ro
a training by
A B
A-api B-api
Extract API modules
No single orchestrator
runtime calls
A B
O
orchestrator
Keep Orchestration Up
= Facade
(eg site?, mobile)
Ways to fix Cyclic Dependencies between Modules
A B
event
call
Fire Events Upstream
⭐️Decoupled
A B
implements
call
Dependency Inversion
⭐️Decoupled
AProvider
AProviderImpl
call
microservices: N/A
microservices: events on queue
microservices: interdependent microservices
microservices: api gateway/saga microservices: shared lib/3rd service microservices: merge?
A B
C
commons
Push Commons Down
Technical:
emails
country
audit, ...
❤️
AB
Merge Modules
if tight
coupling
47. 52 VictorRentea.ro
a training by
B
Surface of a Module
publish events
call
interface
implementation
A
command
(change)
query (read)
(a) notification {id}
(b) fat-event {data}
listen to events
48. 53 VictorRentea.ro
a training by
Segregate in baby-steps
Prepare to stop/undo when needed - incorrect boundary?
Too many tiny modules will 🔝 the Global Complexity
Focus on Data ownership & Flow control
Introduce Events for one-way signals, w/o response
Do NOT sacrifice consistency too early (Transactions, FKs)
Measure progress (eg. ArchUnit, custom tool)
Modulith Lessons
51. 56 VictorRentea.ro
a training by
Reasons to extract a Module into a Microservice
• Different Resource Requirements (eg NOSQL vs RDB)
• Scalability, or go Reactive🔥
• Availability (not impacted by failures in other modules)
• Requires different programming language / exotic framework
• High rate of delivery => independent deployability
• Security posture (vs Wild Wild Web)
• 🛑 STOP if Strong Consistency Requirements: terrible business consequences
• ...
52. 57 VictorRentea.ro
a training by
Module or Microservice?
https://www.confluent.io/resources/event-driven-microservices/
53. 59 VictorRentea.ro
a training by
4) Distributed Systems
1) code decoupling 3) ❌ DB Consistency
2) ❌ Transactions
A
B
A
B
Shared
Transaction
TX
method calls and events
only via doors ✅
External REST API
Foreign Key
Data Replication
(events, CDC, ...)
🔥
MICROSERVICES
🔥
- retry
- idempotency
- queues
- load balancing
- 503
- Network Delay
- k8s, Docker
- rate limiter
- distrib. cache
- circuit breaker
- 😱😱😱😱
TX
>@TransactionEventListener(AFTER_COMMIT)
>@Async @EventListener (worse!)
Tx not shared between modules ✅ Separate Schemas ✅
😱 😱 😱 Eventual Consistency 😱 😱 😱 => Questions to BIZ
Monolith => Modulith => Microservices
Blue Team 👕
Pink Team👚
Partially inspired by Axel Fontaine's talk about the "Majestic Modular Monolith": https://www.youtube.com/watch?v=vV34-3NZkh4
54. VictorRentea.ro
60
Final poll, what architecture have you used by now?
A) Layers: 13/
B) Onion (domain module) 6/
C) Port-adapters (*Port) 4/
D) Feature Slices (*UseCase) 5/
E) Modulith (functional modules in a monolith) 10/
F) Event Sourcing + CQRS 4/
(Total answers: 16/)
55. 61 VictorRentea.ro
a training by
📚
Hexagonal Architecture aka. Ports-and-Adapters
- Original article by Alistair Cockburn, 2005: https://alistair.cockburn.us/hexagonal-architecture/
- Colorful explanation, 8th light: https://8thlight.com/insights/a-color-coded-guide-to-ports-and-adapters
- Input Port Interface are useless: https://softwareengineering.stackexchange.com/q/438705
Onion Architecture
- Clean Architecture Uncle Bob: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- Onion Architecture Primer: https://marcoatschaefer.medium.com/onion-architecture-explained-building-maintainable-software-54996ff8e464
- Original article, Jeffrey Palermo, https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
Vertical Slice Architecture (aka -UseCase)
- Feature slicing Jimmy Bogard talk: https://youtu.be/5kOzZz2vj2o and short intro article: https://jimmybogard.com/vertical-slice-architecture/
- Task-based UI: https://cqrs.wordpress.com/documents/task-based-ui/
Finding Module/Service Boundaries
- Heuristics to find boundaries: https://www.dddheuristics.com/design-heuristics/
- Organize by features, not by entities, Adam Ralph: https://youtu.be/tVnIUZbsxWI
Modular Monoliths
- Majestic Modular Monolith, Axel Fontaine: https://youtu.be/BOvxJaklcr0
- Local Complexity vs Global Complexity in microservices: https://vladikk.com/2020/04/09/untangling-microservices/
Comparisons:
- Comparison of Layered, Onion, vs Vertical Slices, Simon Brown: https://youtu.be/5OjqD-ow8GE
- Nice overview + picture ⭐️ https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/
Task-based UI:
- https://codeopinion.com/decomposing-crud-to-a-task-based-ui/
Books:
- Software Architecture: Fundamentals & The Hard Parts by Neal Ford & Mark Richardson
Architecture Reading
Notas do Editor
Salut! Eu sunt Victor si am 14 ani… de lucru cu Java, desi in ultimii ani am fost impins sa invat si PHP, Scala si C#.
Lucrez la IBM ca Lead Archirect, in Bucuresti. Stiati voi ca aveti un IBM chiar aici in Cluj, intr-un sediu nou-nout. In….
De fapt, cu ajorul IBM sunt astazi aici cu voi.
Stiu deja ce ganditi… aa.. E architect. Sta undeva langa un ficus si deseneaza pe pereti diagrame UML..
-NU . Eu bag la cod. Lucrez pe cele mai dificile proiecte pe care le avem.
La sfarsh:Sala mare -