I spent nearly two years at IBM in Taiwan working on a warehouse management system (WMS) for a major client. This wasn’t a greenfield project where you get to use the latest trendy framework—this was enterprise software that needed to work reliably at scale, integrate with legacy systems, and be maintainable for years to come.
We built the system using Domain-Driven Design (DDD) with a Java four-tier architecture and Spring Boot. If you haven’t worked with DDD before, it’s a way of organizing code around business domains rather than technical layers. Instead of having all your controllers in one place and all your services in another, you group code by what it does in the business context.
For a warehouse system, this meant domains like:
Each domain had its own bounded context, which made it easier for different teams to work independently without stepping on each other’s toes.
When you’re managing a warehouse with thousands of SKUs and hundreds of transactions per hour, database queries can’t be naive. We had to:
One memorable bug: a report query was taking 45 seconds to run. Turns out we were joining five tables without proper indexes. After adding composite indexes and restructuring the query, we got it down to under 2 seconds.
The client had existing systems that weren’t going away. We needed to integrate with their ERP, their shipping software, and a bunch of other tools. This meant:
The warehouse operations team needed real-time visibility into what was happening. We built a dashboard using Azure Analysis Services that pulled data from multiple sources and updated every few seconds. This required thinking carefully about data pipelines and making sure we weren’t overwhelming the database with constant queries.
Domain-Driven Design forced us to think about the business logic first, which made the code much more maintainable. When a new feature request came in, we could usually pinpoint exactly which domain it belonged to.
CI/CD from Day One - We set up Azure DevOps pipelines early, and it paid off. Every commit went through automated tests, SonarQube analysis, and security scanning. When we found bugs, they were caught in the pipeline, not in production.
Four-Tier Architecture - Separating presentation, business logic, data access, and database layers kept concerns properly separated. It felt over-engineered at first, but when we needed to swap out parts of the system, it was straightforward.
One of my specific contributions was using Elasticsearch and Azure Analysis Services to tackle system issues. We were seeing timeouts and slow queries on the reporting side, especially during peak warehouse hours.
I implemented Elasticsearch for inventory searches and complex filtering. Instead of running expensive SQL queries with multiple joins, we indexed the data in Elasticsearch and queried it there. This resolved nearly 65% of critical system issues related to performance.
The key was understanding what data needed to be in Elasticsearch vs. what could stay in SQL Server. Transactional data stayed in SQL; anything that needed fast, complex filtering went to Elasticsearch.
After two years of working on this system, here’s what stuck with me:
Architecture matters - A well-thought-out architecture makes future changes easier. DDD wasn’t just buzzword compliance; it actually helped us organize complex business logic.
Performance is a feature - Users don’t care how elegant your code is if the system is slow. Profiling and optimization need to be part of your workflow, not an afterthought.
DevOps isn’t optional - Automated testing, CI/CD, and monitoring aren’t “nice to have” for enterprise software. They’re essential.
Communication is as important as code - I worked with seven different teams during this project. Being able to clarify APIs, align on metrics, and explain technical decisions was just as important as writing good code.
IBM taught me how to build software that lasts. Not everything needs to be cutting-edge or use the newest framework. Sometimes what you need is solid engineering, clear architecture, and code that other developers can understand six months from now.
Tech Stack: Java, Spring Boot, SQL Server, Elasticsearch, Azure DevOps
Duration: August 2022 - June 2024
Impact: 65% reduction in critical system issues, successful deployment of 50+ RESTful APIs