TheEdonian

Belgian here, never heard of them/the site

__This is a summary of a somewhat long article, it cuts a lot corners due to character limits. Please check the article for more info.__

Some years ago I worked with a scale-up that was really focused on the way they handled data in their product. At some point they started to talk about standardizing their data transfer objects, the data that flows over the API connections, in these common models. The idea was that there would be a single Invoice, User, Customer concept that they can document, standardize and share over their entire application landscape. What they were inventing is now known as a Canonical Data Model. A centralized data model that you reuse for everything. And to be fair to that team, there are companies that make this work. Especially in highly regulated environments you can see this in play for some objects. In banks or medical companies it’s not uncommon to have data contracts that need to encapsulate a ledger or medical checks.

## Bounded context When that team was often talking about domain driven design concepts (value objects, unambiguous language) they seemed to miss the domain part. More specifically, the bounded context. A customer can mean a lot of things to a lot of different people. This is the bounded context. For a sales person a customer is a person that buys things, for a support person they are a person that needs help. They both have different lenses. Now if we keep following the Canonical Data Model, this Customer object will keep on growing. Every week there will be a committee that decides what fields need to be added (you cannot remove fields as that impacts your applications).

## Enter the Data Mesh A way to solve this, is data mesh. This takes the concept of bounded context as a core principle. In the context of this discussion, data mesh sees data as a product. A product that is maintained by the people in the domain. That means that a customer in the Billing domain only maintains and focuses on the Billing domain logic in the customer concept. They are responsible for the quality and contract but not for the representation. That means in practice that they can decide how a VAT number is structured. But not how the Sales team needs to format said model. They have no control or interest in how other domains use the data. It’s a very flexible design but while Data Mesh solves the coupling problem, it introduces a new set of challenges. If I’m an analyst trying to find ‘Customer Revenue,’ do I look in Sales, Billing, or Marketing? The answer is usually ‘all of the above.’ In a pure Mesh, you don’t make multiple calls, you have to build multiple Anti-Corruption Layers just to get a simple report. It requires a high level of architectural maturity and that is something not every low-code or legacy team possesses.

## Federated Hub-and-Spoke Data Strategy Let’s try and see if we can combine these two strategies. We centralize our data in a central lake. Yes, that is back to the CDM setup. But we split it up in federated domains. You have a base Customer table that you call CustomerIdentity that is connected to a SalesCustomer, SupportCustomer, … Think of this as logical inheritance, a ‘CustomerIdentity’ record that is extended by domain-specific tables through a shared primary key. When you create a new Customer in your sales tool you trigger an event. The CustomerCreate event. The CustomerCreate trigger fills out the base information for the Customer (username, firstName, lastName) in the central data lake, at the same time we store our customer (base and domain specific data) in our local database. You also do this for delete and update events. The base information goes to the server, the domain specific data stays on the sales tool as a single source of truth. Every night there is a sync of the domain tools to the central lake to fill out the domain tables with a delta

I might just be getting old, but that post is mainly code and images so using AI to write the very limited amount of text just screams lazy to me.

Makes you wonder if they are as lazy in the rest of their products.

This week I wrote about my experiences with technical and architectural debt. When I was a developer we used to distinguish between code debt (temporary hacks) and architectural debt (structural decisions that bite you later). But in enterprise architecture, it goes way beyond technical implementation.

To me architectural debt is found on all layers.

Application/Infrastructure layer: This is about integration patterns, system overlap, and vendor lock-in. Not the code itself, but how applications interact with each other. Debt here directly hits operations through increased costs and slower delivery.

Business layer: This covers ownership, stewardship, and process documentation. When business processes are outdated or phantom processes exist, people work under wrong assumptions. Projects start on the back foot before they even begin. Issues here multiply operational problems.

Strategy layer: The most damaging level. If your business capability maps are outdated or misaligned, you're basing 3-5 year strategies on wrong assumptions. This blocks transformation and can make bad long-term strategy look appealing.

Here's a pattern I see destroying technical decisions: we've turned meetings into gladiatorial contests of quick wit instead of deliberate problem-solving. Nemawashi, "turning the roots", is a side-step to that.

Pre-socialize decisions through 1-on-1s. Let people think privately, examine data, and reach consensus before the formal meeting. People think better in private, not when they’re performing in front of others.

Since then, I’ve stopped seeing meetings as places for quick wit and started valuing the prep work. The coffee chats, the shared data, the quiet thinking. It’s slower, but it leads to better decisions and fewer grudges.

Except we all know that that vibe coded POC will never be rewritten and if it's a market fit will be pushed to production by management.

These numbers are absurd

How hard would it be to add a GUI to this? I don't think I've seen a lot of GO Gui implementations in the past

Well that would be subtractive: I don't know what I want, but I don't want X & Y. You would steer yes, but it would be very broad. You're not really working towards something, you're working away from multiple things.

Not a real fan of this approach. This is what's called emerging strategy where you react on what happening around you (not to be confused with agile where you look at what's happening around you and then deciding a course of action). Problem here is that you are never in control of where you are going to, and wasting a lot of energy and work switching over to the new strategy.

Looking at the charts they all seem to take off. To me that begs the question, do they take off because they hit the front-page and get all the attention, or are some of them bought upvotes like on Reddit?

Well let's not forget that it's an opinionated source. There is also the point that if you ask it about a topic it will (often) give you the answer that has the most content about it (or easiest to access information).

I like it for what it is, a layer on top of markdown. That said, the main usage of markdown for me is that it's just the content and it doesn't have any opinions on the layout let alone logic.

I can add those with the use of css/js for web and interpreters and themes for print/non web.

I've read so many posts that say: Just write because you like to write, do it cause it's fun.

To me that's only part of the truth. I write because I like it sure, but it's also very unmotivating to just "scream in the void". I want to share idea because I want to hear other opinions on my ideas. I want conversations, not monologues.

How do you earn trust without people getting to the content in the first place?

It's just impossible to get your content out there at the moment. 10 years ago, you would just post on twitter or reddit, and people would catch it. Now, twitter and bluesky are wastelands, and Reddit works if you're in the right subreddit (I say that as my main read/post subreddit just went private this morning without warning).

There are also blogroll communities, but I don't think they are all that popular (if they even let you in).

I heard getting on mailing lists works, but I have no way to even know how you get to that stage.

I’ve seen google launch this same idea a few times now, probably will end the same way as the previous tries.

Didn't Microsoft have a tool/game like this aimed at kids? I remember a youtube video ages ago that generated music from humming or something.

I haven't seen it myself, but I hear: Google I/O 2012 - OAuth 2.0 for Identity and Data Access (https://www.youtube.com/watch?v=YLHyeSuBspI) is a great talk.

I know, this is just an introductory article. You can always take a look at this great book for more info: https://leanpub.com/build-apis-you-wont-hate

You are totally right. Fixed it.

Thanks for reading ;)