Java Application Design

Architectire Vs Design
Architecture is the allocation of system requirements to system elements. Four statements about an architecture:
  1. It can introduce non-functional requirements like language or patterns.
  2. It defines the interaction between components, interfaces, timing, etc.
  3. It shall not introduce new functionality,
  4. It allocates the (designed) functions that the system is intended to perform to elements.
Architecture is an essential engineering step when a complexity of the system is subdivided.
Example: Think about your house, you don't need an architect for your kitchen (only one element involved) but the complete building needs some interaction definitions, like doors, and a roof.

Design is a informative representation of the (proposed) implementation of the function. It is intended to elicit feedback and to discuss with stakeholders. It might be good practice but is not an essential engineering step.
--------------------------------

 Design Architecture
1.  Object Oriented Architecture 
2.  Service Oriented Architecture
3.  Component Oriented Architecture

Object Oriented Architecture - Promotes reusability of by reusing the classes or Objects (Objects are fine grained for effective reuse)

Service Oriented Architecture - This is an architecture style that promotes software reusability by creating the reusable services. (Ex - Web Services) 

Component Oriented Architecture - Promotes reusability of by reusing the components, which consists of set of related classes, their resources and configuration information.
-------------------------------

Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of software systems

 It is more suitable for domain specific & product development softwares.
-------------------------------

Enterprise application Requirements
      
Reliability - representing the how well it maintains its service and service quality (Can be measured no of failures that occurs in given time period).

Availability - Ready for immediate use. It represents the probability that service is available.

Scalability - Handling large no of client interactions.

The above three can be achieved by a platform's support for clustered application deployment environments.
-----------------------------------------------------------------------------------------------------------
Highlevel Design Documents

Domainmodel:

ER Diagram: An entity-relationship (ER) diagram is a specialized graphic that illustrates the relationships between entities in a database. ER diagrams often use symbols to represent three different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes.


----------------------------------------------------------------------------------------------------
Creating a good domain model is one of the most difficult challenges developers have to face. What follows are some advices to create a good domain model

1.- Understand the business model completely.

In order to create a good domain model, developers need to look into the detail of the the business model, not only in the surface. It requires to understand and distill the main entities and then find their closest equivalent software abstractions.

2.- Use good names for all your domain model classes.

Naming is critical in software domain modeling. There are two qualities that you should be looking for in a good name for an entity in your model:
  • Consistent. Business and developers should always use the same term to define a single concept.
  • Exact. A name should exactly define the responsibilities of an entity in the domain model.

3.- Use metaphors.

Many times is necessary to model abstract operations/entities in software development, (processing orders, simulations…), for these cases, metaphors will help you to simplify the design of the domain model.

4.- Make the domain model self-contained.

The domain model should contain the raw logic of the application. Any additional logic should be contained in some other layers, as for instance the work-flow, dependency injection, persistence…

5.- Make the domain model independent.

The domain model shouldn’t change because the underlying persistence implementation or the UI or any other layer changes.

6.- Make the domain model technically simple.

It should only contain POJOs. The responsibilities assigned to an entity in the domain model should be limited to only those necessary for the software domain

7.- Keep the domain model updated.

Synchronize it always with the business domain model, having two unsynchronized models is one of the biggest sources of productivity killers. Synchronization requires refactoring and enough test coverage to make sure that things don’t break as they are refactored.

8.- Make the software domain model match the business domain model.

A software domain model should be easy to understand for a business domain model expert and it shouldn’t have any discrepancy.

9.- Care for the code quality of your domain model.

There are two reasons why you want to make sure that the code quality of the domain model is top-notch.
  • The domain model is the foundation of your application, if it is bad, the whole thing can fall apart
  • It changes a lot. There are very few areas in your code that are going to change so many times as the domain model

10.- Test the domain model independently, and involve the customer in the test.

As already mentioned, the domain model is an independent and very important part of the architecture of the application. That’s why is so important to pay attention to test it in isolation. Involving the customers in this test phase can be very productive as they can identify test cases that are likely in production and which probably are the most interesting ones to test.