Diego Pacheco Tech blog

Service contract design is hard. People do it all the time, but it is not always correct. Most of the time, engineers pay more attention to the service's internal implementation than the contract. A Service contract is the most important part of a service. A good contract provides an abstraction that allows us to have flexibility and allow future refactoring without impacting clients. Being able to refactor code without breaking consumers is pure gold. It's priceless. Not all industries are the same; however, the more dynamic and agile the industry is, the more you need to be able to do Refactoring. To do refactoring more often, you need to make decisions that allow refactoring to happen at a lower cost. If the price of refactoring is always high, no refactoring will happen, and that is game over; that is how we create inadequate legacy systems. A service contract provides a high level of abstraction(ideally) or might(if they do a poor job) leak internal implementation details....

There are many programming languages. Most of them are based on C. However, there are a few different schools of thought. There are imperative, object-oriented, and functional schools and a couple of branches and variations, but that's the mainstream of languages you will see in production in big companies. Programming languages is how we express our intents and turn that intent into value for people. Usually, people are concerned about how other engineers would read the code, make sense of it, and be able to effectively maintain it. System programming languages like C and Zig tend to focus more on performance over abstractions (which always have a cost). Object-oriented programming languages like Java focus more on structure and how to abstract things. Abstractions are not necessarily bad if done right. They have a cost and impact on the people who maintain them. Having more abstractions on the SDK or standard library is a good thing for mantainance and increases people's kno...

After 1+ year of hard work, my second book is finally out. Introducing: Principles of Software Architecture Modernization: Delivering Engineering Excellence with the art of fixing microservices, monoliths, and distributed monoliths. I've 20+ years of experience with technology and have been an architect and a technology consultant for most of this time, software architecture is a deep passion of mine. It is a huge pride and joy, for me to come here today to share this with you, my friends, and dear readers. 🎉🎉🎉 I deeply appreciate all the blessings God has given me, from my family, my daughter Clara, my wife Andressa, my work, and my friends. It was not easy to write this book 📘, there was sweat, blood, and tears, lots of remote work with my co-author Sam . Rest assured you are getting my passion, vision, and perspective of software architecture. First and foremost the book is about principles, tradeoffs, and software architecture design at the heart of complexity. The book is ...

Once upon a time, Design Patterns was a big thing. In current times, perceptions have shifted and the industry has mixed feelings about them. I've thought a lot of blogging about design patterns was worth it or not. I used a lot of patterns in my life, there were moments when I was completely okay with design patterns, and other times not so okay. I got some mixed feelings but today I think they are fine. IMHO there are some fairness and some misconceptions. There are hundreds of Design Patterns, there are patterns for everything you can imagine. Usually when people complain about patterns they are talking about OOP patterns, more specifically from the 90s book from the GOF .   Patterns are not limited to OO, there are functional programming patterns, system programming patterns, OS patterns, cloud computing patterns, frontend patterns, and mobile patterns. Lots of these patterns are very similar, at the end of the day not all problems are that different, and are all about ideas an...

Testing is essential . Testing requires diversity, from integration to chaos , from your local machine to production . Writing tests not always is fun because sometimes is hard to write tests because not all contracts are good, and clean and went through a lot of thought processes. Is easy to blame the design, architecture, and even the implementation, but are we sure we are not missing anything? Something that is hard to test very likely will not be tested. Testability is a good property of any design or architecture sure. Making good solutions that are easy to test is a good thing. However, mocking is often taken for granted, meaning is seen as something that is just good and has no drawbacks, but that is not true. Everything has drawbacks. Integration tests are often seen as bad practices and people tend to lean toward unit tests instead. Just keep in mind Integration tests don't require mocks. Unit tests often require mocks to keep them isolated and cut off external dependencie...

Complexity is everywhere. Small, medium, or big company, does not matter, no one can escape complexity. Complexity just tends to get bigger, we depend on software more and more. Ask yourself, if your subscriptions on iPhone are increasing or decreasing in the last 5 years. There is more competition, and more streaming providers, and everything becomes a subscription, from grocery to transportation to even video games. Complexity increases, maintainability decreases, and maintaining software becomes harder. More software, more complexity. Complexity needs to be fought 24x7 at all times. However, how can we figure out something if we don't fully understand it? Is easy to just give up and do whatever since there is no escape, but there is a better way, we can do better. So what is complexity after all?

Tradeoffs are key for design and architecture. Being able to run proper tradeoffs is an important skill you should master. Decisions we make in software should happen based on tradeoff analysis. Tradeoffs are about pros and cons, which can be done with a simple list of pros and cons. However it looks simple and easy, it is way harder than it looks. Running proper tradeoffs requires knolowsge of the domain, creativity, and lots of debate club skills. Tradeoffs are about trading one thing for another like speed vs. flexibility. Tradeoffs are about balancing factors that might not be attainable at the same time like consistency and availability. Without good tradeoffs skills, we can make wrong decisions and be fooling ourselves. Tradeoffs do not require fancy tools, we can do it with pen and paper, or any plaintext editor like vim. Before we do a deep dive into tradeoffs let's understand why they matter a lot. Why do Tradeoffs Matter? Tradeoffs matter for a variety of reasons: Better ...

Business domains can be very different due to the different natures of each business. Some domains are more static and allow us to easily understand them and produce an efficient core model. However, some business domains are very dynamic, and it is difficult to get the gist and essence of the domain. Some problems require the code to change all the time. The first thing that comes to mind is to externalize business rules either in the form of configuration or in the form of database tables. Externalization to configs and databases works well when the business rules are simple, however, when the business rules are complex, such externalization is more complex and tends to generate more complexity. Nothing is better than code to express complex ideas. Good domain modeling via proper OO design is a very powerful way to map and describe domains.

Elegant Objects is a book written by Yegor Bugayenko  published in 2020. This book call my attention immediately. I've been working with software for +20 years, and in the past, there were many more Object Oriented books(Head First, Design Patterns, Effective Java, and many more), so the very first thing that call my attention was that "WOW feeling" I thought: "OH! An OOP Design Book was written in 2020?" I need to check this out.  Disclaimer : This is not a Rant. This is not a severe critique of the book; this is my toughs. I highly recommend you buy the book and have your own thoughts. I'm avoiding putting code samples here to keep you curious and read the book and also respect the author's work. Maybe read this post again after you finish reading the book. Maybe create your own blog and share your ideas. The book is well-written, concise and goes straight to the point. I saw a commentary on Amazon from a guy complaining that the book is too opinionat...

Factory and Builder and super popular design patterns and still relevant and useful. However what happens if you need to allow others to create objects? That's like a reverse factory where the user needs to define the creational rules. So how can we do that and also have some guardrails and fences to drive some control and even some abstractions, is that possible? yes - that's the factory-kit pattern. Hold one a second why the heck I would need that? Let's say you are creating a game or a modular solution and you need to allow you consider defining customizations within some constraints. 

Reading and writing configs and objects can be more challenging than it looks. As your application evolves and your contract is used across several services, you might need to have Backward Compatibility. Easily we can think about 2 scenarios, the first scenario let's say you have a distributed monolith and you have multiple apps using the same database. The second scenario considers you have an Event Sourcing + CQRS application using Kafka for instance where you emit and read domain events. In both scenarios, there will be breaking changes, so how we can make your parsers and serializers to be more efficient and resilient to change, well: The Tolerant Reader Pattern is here to rescue.

The lazy Loading pattern is very interesting because allows us to make the code starter and also delays expensive computations to an appropriate moment. There is a way to combine this pattern with Java 8 Functional Interfaces and make it even more interesting and java idiomatic. This pattern is used by Spring and Hibernate. You can use it too. So today I have a video and some POC code. Let's get started!

@Configuration allows you to distribute your Spring Beans across several classes and even jars.  However, with great power comes great responsibility. IMHO you should avoid as much as possible ship configurations with @Configuration inside jars. Because it creates binary coupling on Pojos instances and that has a huge blast radius. In IMHO is completely fine to have Config beans inside in your own service however we are considering a shared libs landscape thats a completely different question and IMHO the wrong move. Let's take a look how @Configuration behavior in sense of ordering and with multiple jars being loaded to the same application.

Some technical problems can get quite challenging. It's pretty common to feel like you dont know how to approach them or even panic. Especially if you are starting on technology. Even the most accomplished and experienced feel the impostor syndrome . IMHO if you do not panic is already 90% done 😉, then the next important thing is to keep going. Small incremental progress is essential emotionally wise in the sense of confidence-building. Small wins can be addictive. The first steps are often the most difficult because we are talking about a technical discovery process.  The tech discovery process might sound like something new and fancy, but actually, we are talking about something as old as the rocks: Analysis. But! How do we do this analysis? Which leads us to the questions such as: How to approach complex tasks? How to break problems down? 

Complexity is something that needs to be managed down and is an eternal battle. Part of the battle is to stay away from the style and cosmetical changes. Can we really get 100% of style discussions? Even removing discussions of 2-4 tabs, there will be some form of style on the discussion because every engineer has a background towards JEE, Spring, or Functional. That's a greater generalization, and there are other "design schools" over there but still quite common to find people within these 3 backgrounds. A Philosophy of Software Design is a great book that explains what complexity means. In the book, complexity is mainly described as "Obscurity," something that is not readable and has a high cognitive load to be understood. IMHO some problem spaces require you to have some background and experience on how some problems are solved; otherwise, it might look the worst they actually are. Complexity discussion often hard since lots of engineers have high EGO and h...

Java has 4 visibility options: Public, Protected, Private, and Default. However, is those visibilities enough? Sometimes we need to weigh tradeoffs between different dimensions such as Design, Abstraction, Testing, and Security. C++ Has interesting fine-grained, class-level control with a friend. Java does not have that, but there are some interesting options we do in order to imporve things a bit. Today I want to share a video going through the options we have in Java. I also will show some C++ code so we can see how C++ would handle it. Java also has modules but that is not widely adopted in the industry as most companies still run on java 8. So Let's get started! The Video The POCs  https://github.com/diegopacheco/cpp-playground/tree/main/friendly-visibility-fun https://github.com/diegopacheco/java-pocs/tree/master/pocs/caller-fun https://github.com/diegopacheco/java-pocs/tree/master/pocs/visibility-control-design-poc Cheers, Diego Pacheco

Every company has a legacy code. Often we confuse legacy with multiple different concepts, and this confusion makes improvements harder to happen. Most engineers don’t like to deal with legacy code-we all like shiny new things. Unfortunately, most of the time, there is no easy way out. It is possible to replace a legacy system with a brand new system because it is easier and faster than fixing all the legacy’s problems. We can’t get out of legacy systems because they have old languages, old databases, and often messy. Is that so? However, there are 2 kinds of old languages. The ones who are dying and dated like Delphi or Clipper and the other ones are old but are perfectly fine to use C++ or Java. I’m not defending legacy systems; however, I believe several essential aspects need to be considered. Old: Mature vs. Dated Commonly, we confuse mature software with dated.  Boring technology  is full of good arguments there. Old technology not necessarily means it is terrible. ...

Normalmente eu nao blog em português, mas hoje quero compartilhar um programa que participei recentemente. Programa gravado com o Inacio da South System sobre Arquitetura de Software, mais especificamente falando de Microservices, SOA, Shared-Libs e bem como os problemas e as soluções. Microservices estão em baixa nos dias de hoje. Porém muitas vezes não entendemos por que estamos usando microservices e nem por que estamos parando de usa-los. Muito difícil conversar sobre SOA e microservices sem falar de shared-libs e o impacto nessas arquiteturas. Nessa conversa você ira entender mais os problemas desse landscape bem como muitas alternativas para editar esses problemas. Entao bora la ver esse video! 

SOA(Service Oriented Architecture) is all about contracts. Contracts can either be managed explicitly by doing Contract First, Customer-Driven Testing, having POs manage the contract as an important asset as much as a UI is. Contracts can also be unmanaged or managed implicitly just pushing problems to consumers and making the whole org move slowly. So what is a contract anyway? Why should we care?  The contract is all Data, Behavior, and expectation involved in the services capabilities. It's easy to see just the endpoint's input and output data and forget about the rest. The rest is smaller things like data formats, access protocols, serialization formats, and do not forget about expectations. For instance let's say you are returning a list of customers, if the data is in ascending or descending order it might affect your consumer code or tests.  Contracts cab be versioned and we should have specific tests on the Implementation provider side in order to make sure we don...

There were some interesting posts about UML recently. Mainly being  “   Has UML died without anyone noticing? ” and “   Why UML “Really” Died ”. I also made some po s ts about UML in the past — mainly “   UML Hidden Gems ” and “   Architecture 101: Thinking about Design ” and “   Internal System Design: The Forgotten Discipline   “. IMHO success means decline and eventually abuse. That happened to all successful movements, technologies, and methodologies I can remember such as Agile, Architecture, DevOps, Docker, Spring, and many more. Yes UML was abused and used in the context of the heavy and rigid process. UML was often used for all CRUDs which does not make sense and does not add value. But honestly, if we see things with DDD lens even CRUDS don’t make sense especially with UX sense CRUD are not ideal at all. IMHO what happens is we are exposed to fashion and marketing. There is internal and external pressure to do things in one way instead of anot...