Mastering Software Methods: From Business Modeling to Domain‑Driven Design

Introduction

The article presents a systematic learning approach for software engineers, emphasizing that mastering software methods can greatly improve understanding, efficiency, and product quality.

Background

Many engineers lack solid skills in business abstraction, domain modeling, and architecture design despite rapid advances in technology and frameworks. This leads to declining capabilities and poorer system maintainability.

What Is a Software Method?

According to Baidu, a software method is a set of suitable techniques applied throughout software development—from requirement analysis to maintenance—to solve problems efficiently and meet user needs.

In practice, it includes design principles, design patterns, domain modeling, and business modeling, forming a complete methodology.

Why Is It Often Ignored?

Technical focus over business value, ignoring scalability and maintainability.

Business and domain modeling are seen as crafts that require extensive practice.

Importance of Software Methods

A good software product requires deep business understanding and abstraction. Proper methods improve design quality, reduce costs, and enhance personal and team value, leading to clearer career paths.

Software Method Overview

Before development, consider three questions: (1) Will requirements change? (2) How to make the product more sellable and reduce costs? (3) How to use modeling to uncover value and lower implementation costs.

1. Requirement Variability

Most human needs (e.g., paying, eating, traveling) remain stable, but implementation methods evolve with technology, creating new opportunities.

2. Enhancing "Sellability" and Reducing Costs

Profit = Revenue – Cost can be reframed as Profit = Demand – Design. Effective modeling extracts true demand and creates efficient designs.

3. Practicing Modeling

Modeling covers business modeling, requirement analysis, domain modeling, and software design, each improving product value and reducing development cost.

Business Modeling

Identify the value an organization provides to others. Distinguish between the "primary" stakeholder (the payer) and other stakeholders. Use business use cases and business sequences to capture this value.

Business Use Cases

Define the actors and the use cases they perform (e.g., depositors and borrowers in a bank).

Business Sequences

Illustrate how actors and systems collaborate to deliver value, showing evolution from manual teller services to ATMs.

Requirement Analysis

Derive system use cases and specifications from business sequences. System use cases include actors, pre‑conditions, post‑conditions, main flow, extensions, business rules, quality requirements, and design constraints.

Domain Modeling

Domain‑Driven Design (DDD) treats business areas as domains. Core steps include event storming (identifying domain events, commands, and nouns), building domain objects, and defining relationships.

Event Storming

Identify domain events (e.g., "Funds Deposited").

Identify commands that trigger events (e.g., "Deposit Funds").

Extract domain nouns (e.g., "Depositor", "Account").

UML Relationships

Six fundamental UML relations are used in domain modeling:

Association : bidirectional link between classes.

Dependency : one class uses another.

Composition : part cannot exist without the whole.

Aggregation : whole‑part relationship where parts can exist independently.

Generalization : inheritance hierarchy.

Implementation : class implements an interface.

Software Design

Design includes high‑level architecture (physical, logical, data) and detailed design (interfaces, tables, class diagrams, state machines).

State Machines

Model object lifecycles by defining states, events, conditions, and actions (e.g., fund status: normal vs. frozen).

Rich vs. Anemic Models

Debate whether business logic belongs in entities (rich model) or services (anemic model). Rich models encapsulate behavior but can become complex; anemic models separate data and behavior, offering flexibility.

Aggregate Roots

Operate on aggregate roots to maintain invariants and transactional consistency.

Application Layering

Suggested layers:

Adapter (Gateway) : handles external requests, security, and authentication.

Application : orchestrates domain services, thin logic.

Domain : contains business logic, entities, value objects, and domain services (preferably anemic model).

Infrastructure : provides DB, cache, file services via abstract clients.

Conclusion

Software methods constitute a holistic mindset from business understanding to design. Mastery of these methods improves delivery efficiency, product quality, and career development.

Reference materials: Pan Jiayu "Software Methods – Volume 1", Zhong Jing "Hands‑On DDD".