Layered Architectue

Charith(044015)

Domain centric means to derive all design from a business architecture perspective.

Domain-driven design (DDD) is an approach to the design of software, based on two premises .For most software projects, the primary focus should be on the domain and domain logic (as opposed to being the particular technology used to implement the system) Complex domain designs should be based on a model.

The term was coined by Eric Evans' book of that title. The book articulates a number of high-level concepts and practices, such as: Ubiquitous language: the domain model should form a common language for describing system requirements, that works equally well for the business users or sponsors and for the software developers. plus a number of specific software design patterns, such as: Entities (a.k.a. Reference Objects): An object in the domain model that is not defined by its attributes, but rather by a thread of continuity and identity. Value Objects: An object that has no conceptual identity. These objects describe a characteristic of a thing. Repository: methods for retrieving domain objects should delegate to a specialized 'repository' object such that alternative implementations may be easily interchanged. Factory: methods for creating domain objects should delegate to a specialized 'factory' object such that alternative implementations may be easily interchanged. Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services.

The goal is to construct a technology independent application that retains business objects in original form. To do this an application’s architecture is decomposed

This approach while simple supports long term growth using highly cohesive and loosely coupled software layers that allow change in technology and business processes that would otherwise cause failure in most software structures.

Presentation layer

This is where you find the user interface logic. This logic captures how a user (or other actor) interacts with the application. This interaction includes a common look & feel, and work flow specific to each actor. In addition to each view there may be more than one type of presentation, i.e., (Web, Thick Client, Wireless Application Protocol, etc).

All presentations and views are built on top of the same domain model. Handles presentation layer requests, Defines jobs the software is supposed to do. Coordinates tasks and delegates work to collaboration of domain objects in the next layer down. Can have state that reflect the progress of a task for the user or the program.

Application layer

This layer mediates between the various user interface components on a GUI screen and translates the messages that they understand into messages understood by the objects in the domain model. It is responsible for the flow of the application and controls navigation from window to window. This layer is often partially generated by a window-builder and partially coded by the developer.

Domain Layer

Heart of business software. Technical detail of storing these rules is delegated to infrastructure. Handles application layer requests. A couple of key design goals are

Capture and retaining the business architecture in its purest form. Support for multiple presentations and views without need for specific customization of the domain layer to the needs of any one specific point of view.

When driving software construction from the domain layer the concepts within this layer are reflected outward throughout the other layers in a vertical fashion. Once again reinforcing the idea of driving design from the business architecture.

Persistence Layer

Persistence is where we map data to/from the domain model and long-term storage

By encapsulating persistence in its own layer of functionality it could even be implemented as a remote interface to a distributed system instead of directly talking to an underlying storage device, and from the domain model’s perspective this would be transparent.

Benefits of Layered Architecture

Separating the domain layer from the infrastructure and user interface layers allows a much clearer design of each layer. Isolated layers are much less expensive to maintain, because they tend to evolve at different rates and respond to different needs. This seperation leads to reuse.

1. Modularity, low-coupling – easier maintenance.

2. Business-logic is separated from presentation – reuse.

3. General technical services, e.g., database, are

separated from the business-logic – reused, replaced.

4. Low coupling, separation of concerns – evolving functionality, system scaling-up, adapt to new Technologies

The separation also helps with deployment in distributed system, by allowing different layers to be placed flexibly in different servers or clients, in order to minimize communication overhead and improve performance.

Added by Indika (044051)

Smart UI Anti Pattern

So far we have discussed layered architecture related to domain isolation. Actually it is ideal for software project with more functionalities and more complex domain requirement.

Consider a small project with simple functionalities. If we select domain driven approach the design of the project will became more sophisticated. It may require some time to design the architecture in layer wise But more frequently those projects are given limited time to complete. This type of situation to it is better to choose smart UI anti pattern approach to carryout the project in very simpler and productive way.

What is Smart UI Anti pattern?

Smart UI anti pattern is alternative for layered approach and mutually exclusive from domain isolation. It decouples all the layer functionalities and embedded in to the user interface. So we can’t see any domain isolation here.

Where to apply Smart UI anti pattern?

Case 1:

Suppose Software Company is given a project with simple functionality and it has short time period to finish the project. Still all the domain requirement has not been verified it will take some time to clarify the entire domain requirement. Also there is a possibility of changing business functionality is very high.

Case 2:

Suppose a company has junior staff and they are not experience in domain driven design approach at all. If the management decided to do the project using domain driven approach, it will require considerable time to train the staff. But it is not productive with given time schedule of the project. And also it has some risk as they are doing this type of project in first time. So the possibility of the failure is very high.

Case 3:

There may be situations all the domain requirement has not been clarified and but customer need some modules to be finished with clarified requirements. If we select domain driven approach we have to wait until the domain layer is finished. So it is not possible to release a module of the project with identified requirements. So again smart UI anti pattern approach is ideal to address these types of situations.

Advantages

1. Productivity is high and immediate for simple applications.

It will take less time to finish each module and earn profits.

2. Less capable developers can work this way with little training

3. Even deficiencies in requirement analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit there requests.

4. Applications are decoupled from each other, so that delivery schedule of small modules can be planned relatively accurately. Expanding the system with additional, simple behavior can be very easy.

5. Relational databases work well and provide integration at the data level.

6. When applications are hand off, maintenance programmers will be able to quickly redo portions they cant figure out, because the effect of the changes should be localize to each particular UI.

Disadvantages

1. Integration of applications is difficult to except through the databases

2. There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply.

3. Rapid prototyping and iteration reach a natural limit because the lack of abstraction limit refactoring options.