System architecture describes the components of the system. For example you might have an order entry system that consists of:
Web Front End, Business Layer Service, and Data Store.
So, you should a high level diagram showing this.
Software application architecture describes the architecture of a particular component. For example, one of the components of the order entry system is the web front end. The application architecture will show the various layers and interactions of that component. Responsive UI, Model View Controller, web service call outs, how logging will be accomplished, etc. It gives and idea of the each component will be constructed and the layers in that component which is a part of the larger system.
usually a more detailed diagram(s) showing how that component will be constructed is created.
Finally, Class Diagrams dive deeper into the software application architecture. For example, what's the contract for the logging interface look like? How will View interact with the Controller... and so forth. These will further detail the software application architecture for a particular component of the system.
There should be many of these if the particular component is large and complex.
It's all about semantics.
Enforcing layers will help to keep the code clean in responsibilities. (Single responsibility principle). Your mental stack will be minimized in each layer when separating concerns. And you gain flexibility in interchanging layers.
Using layers is the vertical way to organize code mass. And that is the same with organizing people. You have to spent more time in organizing them if you have more people.
One thing to microservices:
They do not adress layers, they adress the horizontal way (functional way) to organize code mass. Here again: More code, more separation. But be careful:
Microservices may give up consistency if they are missing the "bigger" context of your whole domain. So if I design microservices they are an outbound view of parts of my business domain model considering global consistency.
So most of the time I would not divide the business layer into smaller pieces as you may loose the possibility to check global constraints OR you will have to consider these consistency constraints in your microservice protocol, making them a lot more complex.
For me UI, Usecases, Business logic and DAO layers are essential and univeral in semantics. I don't think we have to discuss about the UI. Usecases will model the current work flow of a user. Business logic will check local and global constraints to ensure system-wide consistency, furthermore it orchestrates the DAOs. And the DAO layer will abstract from the type of data holders.
After all only one thing matters: The maximum profit of the business you are working for. So your expenses to separate concerns should be balanced with the income achieving with the application to the maximum profit.
Best Answer
I'm a mobile developer who has spent a great deal of time considering this issue.
Why do you ask?
Most likely, you hope to reduce app development costs by:
Reasons may also include:
Definitions
Let's establish exactly what we mean by each of the three approaches mentioned:
Native
An app that is installed on a device, usually from its app store (although can sometimes be sideloaded). For the purposes of this discussion, the UI of a native app does not usually consist of a full-screen webview only.
Mobile web
This can in fact be any web page at all, however for this discussion let's consider a single-page web app which attempts to imitate the look and feel of a native app. It is not a native app, it runs in the device's browser.
Hybrid
Hybrid app
instanceofnative app.Most people probably understand a hybrid app to be a single-page mobile web app (again most likely imitating the look and feel of a native app), but packaged as a native app with access to native services (à la Phonegap).
However there is in fact a spectrum between the Phonegap model and fully native which I'll come to later.
Mobile web
Technical restrictions
Let's first list some technical restrictions on mobile web apps which could in themselves be deal-breakers depending on what you're doing:
If you can live with all the above, then read on for more about the challenges of single-page native-style web apps. However this section wouldn't be complete without reference to the FT app.
Financial Times
The FT web app is a famous example of this style of app. Here's an interesting feature from the UK Guardian newspaper about it.
It's certainly a remarkable feat of engineering. Note that it is currently still only available on iOS only -- this tells me that they are finding that resolving the challenges of advanced cross-browser development to be very difficult indeed.
Single-page native-style web apps
This section applies to both mobile web and Phonegap-style apps.
Native-style look and feel within a web app is usually achieved with a framework such as Sencha Touch which provides a suite of UI components for you to use.
Such frameworks are fine for very simple UIs. However they lack flexibility. You won't be able to implement any native app design using Sencha, you'll need to adapt your design to what the framework can accommodate.
The main way in which these frameworks suffer is in trying to emulate the platform's own UI intricacies. That nice little bouncing effect you get when you've scrolled to the end of a list on the iPhone? Your framework needs to emulate that in Javascript. It's impossible to recreate it completely, it will be prone to slow down, and your users will be stuck in the the "uncanny valley" of an app which looks sort-of like native, but clearly isn't, and a non-technical user won't be able to put their finger on exactly why.
The "HTML5/Javascript is easy" myth
Device fragmentation within web browsers is rife, and when you get beyond the most basic HTML and CSS you'll notice things don't quite work as you'd expect. You might find yourself spending more time solving fiddly UI issues than you'd have saved doing it natively twice over. If you're going native, note that native app webviews are not the same as device browsers and have their own fragmentation issues.
And as your app gets more functionally complex, you'll find that you need more than basic jquery skills to keep your Javascript clean and maintainable.
That said, it's perfectly possible to create simple, functional apps pretty quickly with this approach. But it's pretty obvious when an app is doing it.
Further along the spectrum
So, we want a better UX than Phonegap-style apps can offer, without writing absolutely everything from scratch multiple times. What can we do?
Share non-UI code
There are a range of techniques available for sharing business logic across multiple native platforms. Google have launched J2ObjC which translates Java into Objective-C. With careful factoring of code, a Java library could be used on both Android and iOS.
Libraries such as Calatrava and Kirin allow codebases written in Javascript (and therefore anything that can be compiled to Javascript) to be manipulated from native code. Disclaimer: I work for Future Platforms who created Kirin; we have had great success using it on iOS with Javascript generated from Java with GWT, with Java code also being run natively on Android.
Use webviews... where appropriate
Full screen webviews have a lot of work to do to be able to imitate screen transitions and bounce effects. But a webview inside native app chrome can be indistinguishable from native.
There are standard and well documented methods for native apps and webviews to communicate.
Lists and tables can work particularly well when done in this way, however text entry is an example of something best handled natively (for full control over keyboard).
In summary
The approach that's right for you depends on how complicated your app is, and what level of UI polish you'll be satisfied with.
My motto: use webviews wherever you can, but make sure your users can't tell.