Stepping Into the Unknown: My First Steps in Web Domain Analysis and Back-Office Structure Design
In July, I joined a group of talented engineers and moved into our company’s subsidiary. Our job sounded exciting — and a little scary. We needed to modernize an old Japanese banking system and move everything to the cloud.
My first task was to understand the web-related domains and estimate their size for resource planning. As I had a bit of experience with Domain-Driven Design before, so I raised my hand for this task. But when we saw the code, it felt like opening a time capsule from decades ago. The system was a giant monolith, the logic was hard to follow, and there were no documents to guide us.My manager suggested classifying thousands of source code files and grouping them into categories. Well to be honest, for a moment, it really felt like mission impossible.
At first, the plan was for me and a senior colleague from the legacy bank system side to work on this classification together. But since I was new and had no real understanding of the business yet, I felt he was much better suited for that work. So I asked him to take full ownership of the source-code classification, while I chose a different path — starting from the official website and building my understanding from the user side. I borrowed several test credentials, explored every corner, talked to many people, asked countless questions, and slowly built my own information architecture.
Later I compared what I built with the senior colleague’s classification to make sure nothing was missing. If you ask me what the hardest part was, it must be the Japanese banking terms. Sometimes even understanding the name of a feature took much longer than expected. But piece by piece, I put the puzzle together.
Just when I felt I was making solid progress, my next task arrived: try to analyze the back office.
This was a whole new world. I had never worked on BO before. I even had to start by asking ChatGPT what a back office usually does. Based on my past development experience, my first instinct was that permissions would be both the hardest part and the best entry point. And I was right. It was my first time seeing a real role-based permission system at this scale. A truly large permission design — and I couldn’t help feeling impressed.
Around this time, the company also started discussing how the new BO should be built. Should one large team take care of everything? Or should a small BO core team collaborate with each domain team? For the first time in my career, I began thinking about team structure, collaboration cost, and organization-level risks — things I never needed to consider before.
Get Sophie Ha’s stories in your inbox
Join Medium for free to get updates from this writer.
Here’s how I see the BO development structure options:
Time Cost
A single large team can start quickly. A BO core + domain teams need time to agree on boundaries and collaboration rules. But later, domain teams may move faster because they already understand their business deeply. Their product lines also feel more natural.
Human Resource Cost
Both approaches need to build the same BO. But when resources are limited, domain teams can be moved flexibly to support either the BO or the website.
Operational Cost
A single-team BFF model makes life easier for the frontend, but requires extra mapping logic.
Communication Cost
Communication is faster within one large team. In a collaborative model, unclear domain boundaries can cause long-term debates.
Risk
A large team may become a bottleneck, but this can be eased by hiring more people or splitting the team.
The collaborative model carries a deeper structural risk: if domain boundaries aren’t clear and the BO core absorbs all the “gray zones,” it may become an even bigger bottleneck.
Later, pushing company-wide changes (especially compliance) also becomes harder when many teams work independently.
Because of all these reasons, I personally feel that one large team is the safer and more practical approach.
As I write this, the back office is still a black box to me. Its simple-looking UI hides countless business flows. But for the first time, I feel close to real business. For the first time, I see what true system architecture looks like. For the first time, DDD feels real — not just a theory in a book.
My manager told me, “Just enjoy the challenge.”
I know this is only the beginning.
We’re building something new, step by step — and we’re sure to turn our blueprint into reality :)
