1.2 Modeling Workflow

1.2.1 Modeling Workflow ABCD

To create good requirements and designs, and thereby produce marketable systems at low cost, it's not enough to just shout slogans. It requires patience to learn and practice necessary modeling skills.

Software development is incremental and iterative. Each iteration cycle needs to consider the following aspects in sequence:

A-Business Modeling — Identify the target organization that needs improvement and the most pressing issues that need to be addressed.

B-Requirements — Describe the overall performance that the information system to be introduced must have to improve the organization's problems.

C-Analysis — Refine the core domain mechanisms that the information system to be introduced needs to encapsulate to meet functional requirements.

D-Design — Consider quality requirements and design constraints, mapping core domain mechanisms to selected non-core domains for implementation.
This book refers to the above ABCD as the four modeling workflows of software development.

If using this book's methodology and UML notation, the ABCD would roughly look like Figure 1-5.

Figure 1-5 Four Modeling Workflows (This Book's Methodology + UML)

Various fancy terms in the software world, whether genuinely innovative or pseudo-innovative, can basically be summarized using the above ABCD, for example:

Product Manager, Requirements Engineer, Requirements Analyst: A+B+partial C.

Business Architect: Could be A (where "business" means "organization"), or C (where "business" means "core domain").

System Architect: C+D. Teams often say they want to improve system architecture, but what they actually want to improve is B-Requirements.

Domain-Driven Design: C+D. Some teams claim they want to learn "Domain-Driven Design," but what they actually want to solve is A-Business Modeling.

Microservices: C+D

Design Patterns: C+D

......

Readers are welcome to add and update at any time.