How to structure your company to have organized software
A well-organized software system is the bare minimum for the success of any technology-driven company. In this article, I’ll outline key concepts for structuring your business efficiently.
Business Domain: The Heart of Your Company
The business domain represents a company’s core activity, encompassing innovations, optimizations, specialized knowledge, and intellectual property. It is what sets your business apart in the market, providing a competitive edge.
To be effective, the primary domain should be treated as an internal solution, carefully developed to meet the unique needs of the business.
Subdomains: Categorizing Different Business Areas
Not all parts of a system have the same complexity or strategic value. Therefore, they should be classified into:
- Core Subdomain
- Represents the essence of the business—naturally complex and a source of competitive advantage.
- Never neglect or take shortcuts here, as it holds the highest value.
- Generic Subdomain
- Addresses problems already solved in the market. May be complex but offers no competitive advantage.
- Supporting Subdomain
- Handles simple problems that assist the business (e.g., system logs).
Domain Experts and Ubiquitous Language
Working with domain experts—people who deeply understand business rules and requirements (often end-users)—is essential.
Ubiquitous Language is a standardized form of communication used by everyone involved in the project:
- Eliminates ambiguity and unnecessary technical jargon.
- Must reflect both the business domain and expert models.
- Applied in requirements, tests, documentation, and code.
Managing Complex Models with Strategic Design
Software models should be **useful and consistent**, meaning functional divisions must make sense. Breaking the system into **bounded contexts** (implemented as independent services or modules) is critical.
Integrating Bounded Contexts
Integration between different system parts can be achieved through:
- Shared Kernel
– Integration contracts are shared across teams.
– Changes are costly, as they impact multiple areas.
- Customer-Supplier
– One team provides services to another.
– Often involves a power imbalance.
- Conformist
– The “upstream” team dictates rules, leaving little flexibility for the “downstream” team.
– May cause frustration without proper support.
- Anti-Corruption Layer
– Similar to the conformist model but includes an intermediary layer to protect the downstream system.
- Open Host Service
– The provider separates internal implementation from the public interface.
– Enables evolution without disrupting consumers.
Conclusion
A developer’s daily challenges should stem from technical problems—not unnecessary complexity. Eliminating ambiguity in design ensures smoother teamwork. While technical debt is common, a clear strategy is needed to prevent accumulation.
A real-world example of how bugs can derail delivery is in the fifth point of The Joel Test: 12 Steps to Better Code, which describes how Microsoft Word’s team took years to ship features due to massive technical debt.Never underestimate the impact bugs can have on your system—small issues, when ignored, can snowball into critical roadblocks.
