The so-called process is actually parts of the architecture, and the so-called architecture is actually parts (use cases) of the process

The so-called process is actually parts of the architecture, and the so-called architecture is actually parts (use cases) of the process. Both of them are about three things:

1. use cases
2. data fields
3. architecture use cases (transaction-failure handling; network-performance plus offline client, reports, direct database jobs; security, auditing)


Key understanding:

1. use cases: this is the art. The core of the art is to find the representative use cases so that they are only a few but cover all data fields. Also note that they need to be described using UI terms, however, they are use cases -- using UI language and eventually doing UI design do not mean you need to jump on UI design in the very beginning.

2. data fields: this is the science. All computing are based on this, including object oriented programming -- the core of domain model is in data model. However, note that this does not mean you need to jump on database physical design in the very beginning.

3. Architecture use cases. They are use cases. "Architecture" is not magic; they must be organized in use cases. Users can and must understand them -- that is, if you organize them in use cases.