Copy
View this email in your browser

Dear Architect,

Welcome back to our weekly issue!

This week we have in our spotlight a case against implementing a centralised platform team inside your organization. As you probably understood I like to see different sides of the same coin and understand why some practices work or why not. That's why I'm sharing the same topic from different angles because the context leads to find you the best trade-off for making a business successful.

I found very useful this DDD modelling process because leverages all the principles I believe we should follow when designing software architecture.

Last week was published a paper on micro-frontends that I took part in. I believe it's interesting because there is an academic approach for analysing all the resources.

I realised we don't talk much about databases, but when we choose one we should understand the characteristics behind it. This article is the first I found sharing behind the scene, hopefully, I'll be able to find more for the next issues.

Finally, another perspective on event sourcing, this article is presenting the cons of embracing event sourcing considering often we read only about the benefits.

Enjoy the read and see you next week!

In the SPOTLIGHT

Team Topologies

A case against “Platform Teams”


It is better to operate multiple platform teams specializing in their own techno-business domains than to operate a single platform team.
Platform Thinking is not about reuse, it is about facilitating evolution, and fixating on reuse destroys that opportunity.
Instil platform thinking in all teams and allow self-reliant domains and platforms to emerge organically instead of forcing the issue up front.
Domain-Driven Design

Domain-Driven Design Starter Modelling Process

Using this process will guide you through each of the essential steps in designing a software system with the DDD mindset, so you can focus on your business challenges and not be overwhelmed by learning DDD at the same time.

Micro-Frontends

Motivations, benefits, and issues for adopting Micro-Frontends

The goal of this work is to map the existing knowledge on Micro-Frontends, by understanding the motivations of companies when adopting such applications as well as possible benefits and issues.

Databases

Become a Database Expert by Knowing the Pros and Cons of LSM Tree and B-Tree Engines

It is paramount to understand the underlying storage engine within these databases to explain how databases deliver these promises. For instance, why are relational databases very useful for performing transactional operations? What is the storage engine underlying SQL that makes transaction operations a good fit?
Event Sourcing

Stop overselling Event Sourcing as the silver bullet to microservice architectures

Software engineering, as a culture, seems determined to sell each other on solutions based purely on some benefits, without consideration of context, complexity and cost. If you are not using complicated architecture pattern X or infinitely scalable message broker Y you are doing microservices wrong.

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

HELP US TO IMPROVE THIS NEWSLETTER!
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!
Twitter
Website
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