View this email in your browser

Dear Architect,

Welcome back to our weekly issue!

Let’s start this newsletter with an analysis of where we are today with microservices and how, in the future, abstractions will proliferate for facilitating our job. The article has many insights from well-known practitioners like Sam Newman and Daniel Bryant. 

In Martin Fowler’s blog we can always find some gems, and there is a new series of articles on legacy displacement that I found a spot on so I wanted to share the first one about identifying the boundaries of a legacy application and start to refactor it.

Once again microservice, this time we are going to discover the GitHub’s journey from a monolithic architecture to a distributed system.

I found interesting to read a fresh perspective from a new DDD practitioner. In this post we can find three challenges encountered during the journey to DDD.

Finally, governance and people in the data ecosystem. I listened to this episode during my commute time and once again I saw the main challenge for successful projects are not architectural but are around people and how we set up for success in our company.

Enjoy the read and see you next week!



The Future of Microservices? More Abstractions

For better or worse microservices have become, for many, the default architectural choice. For organizations with autonomous teams and loosely coupled systems, microservices can work well, but they bring the complexity inherent in working with any distributed system.

Design Patterns

Extract Product Lines

Many applications are built to serve multiple logical products from the same physical system. Often this is driven by a desire for reuse. "Hmm, consumer loans look quite similar to business loans" or "clothes are a product, so are made-to-measure curtains, how different can they be?". A major problem we come across is that superficially the products look similar but they very different when it comes to the detail.

Case Study

GitHub’s Journey From Monolith to Microservices

Good architecture starts with modularity. The first step towards breaking up a monolith is to think about the separation of code and data based on feature functionalities. This can be done within the monolith before physically separating them in a microservices environment.

Domain-Driven Design

Challenges implementing DDD

I would say that DDD is a really complex topic and there are a lot of approaches and patterns, so I would not even try to cover them all here. I would just summarize that DDD is all about understanding the business domain and appropriately reflecting it in the code.

Data Governance

Data governance: The foundation of data-driven organizations

With the advent of big data analytics, powered by the ease of moving data to the cloud, the pressure on companies to get data right to make million-dollar decisions in a few seconds has become paramount. How can organizations set themselves up for success when it comes to data?

Thanks for reading Dear Architects 🙏

If you have any suggestions to make this newsletter better, just drop us an email!

Have a great rest of the week 😉

Opinions are my own

We just need a few minutes of your time to make Dear Architects even better
Sure! Let me share what I think about Dear Architects!
Copyright © 2021 deararchitects, All rights reserved.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp