This week I had the chance to attend @kandddinsky and it was great.

Thanks to all the organizers and attendees for an excellent few days.

And thanks to @eduardodasilva for another enjoyable and memorable collaboration.

Slides: https://drive.google.com/file/d/1LajO--r77CIl5FOfdrCCoz2WzmNE652f/view?usp=sharing

#architecturemodernization

The common perception of a software architect is someone who designs systems.

But I think a good architect is someone who can actually get designs off the whiteboard and into production.

Decision making, delivery management, organisational change, and facilitation skills are all crucial.

I like how @xinyao says "architects architect the [architecture] process".

I met a lot of clients who had great visions that never went anywhere.

#softwareArchitecture #architectureModernization

Architecture modernization anti-pattern: accessing another subdomain's data from the legacy system*

When building something new outside the legacy, you might be tempted to go direct to the legacy system to read/write data that you require (via the DB, CDC, or EDA).

If that data does not conceptually belong to the subdomain that is accessing it, you are breaking encapsulation: you are going via the backdoor to access another subdomain's data

1/3

#architectureModernization #ddDesign

Where should you put the anti-corruption/translation layer when migrating from a legacy system?

1. in the legacy
2. in new code
3. a dedicate translator service

A benefit of 1: fully encapsulate the legacy model and prevent it leaking

A benefit of 2: teams don't have to make PRs in multiple codebases for the same feature (when the ACL needs to change)

1/2

#architectureModernization #legacyMigration #softwareArchitecture #ddDesign #domainDrivenDesign

One thing I love to see in an ADR is when the author goes into a little detail* about potential solutions that weren't selected.

It gives me the confidence that the author has really challenged their gut instincts and biases around what they think is the correct solution.

Even if the other options are clearly inferior, it shows that the author was aware of them, and considered them, and can clearly articulate why they are not preferable.

#softwareArchitecture #architectureModernization

The cost of deferring some software architecture decisions can be significant.

As teams continue to build new features while awaiting clarity on an architectural direction, they make short-term choices or add avoidable complexity.

Example:

"[for this new feature] We are going directly to the big shared database rather than establishing clear interfaces.

...

1/2

#softwareArchitecture #architectureModernization #ddd #domainDrivenDesign

When modernizing your legacy systems, be careful not to automatically assume that the language your business and domain experts use is correct and should be reflected in your new architecture.

Their language might be influenced by your legacy systems and not an accurate reflection of the concepts in your domain.

Here is the kind of conversation I've had many times...

1/3

#ddDesign #domainDrivenDesign #softwareArchitecture #architectureModernization #archModernization

Yesterday I said something a bit naughty live on @ewolff's architecture stream.

I said that sometimes you should do your architecture modernization in secret.

Of course this is not the default. It's very risky and there are nuances.

What I mean is, sometimes you don't need to over-share your implementation details.

if you say "we will refactor the domain model while modernizing" - people might be worried that you're going to over-engineer.

1/2

#architectureModernization