mercredi 30 mars 2016

Do you like spaghetti or Lasagna


The spaghetti Pattern is an anti-pattern because we can't find any structure clear, most of the components are not reused after and it's not easy when we try to improve or to add other parts, and produce regression in maintenance.
So, why some developers use this pattern? 
the reason that this type of development pattern is initially popular because it's the easiest and the fastest way to let going. No need to plan, then just start and correct, so the test is easier because it depend from a small code. In the maintenance process, whenever new features are added to the Spaghetti Code code base, we have to do not modify the Spaghetti Code simply by adding code in a similar style to minimally meet the new requirement. The more tightly integrated individual parts of the application are, the more indistinguishable there are from each other. Tight coupling prevent code reusability and leads to duplication.
Who use it ?
This is Pattern demonstrated by people new to object-oriented development, with lake experience in software architecture, who map system requirements directly to functions, using objects as a place to group related functions. Each function contains an entire process flow that completely implements a particular task.
Solution : Lasagna Pattern - Layered architecture - Divide and conquer (derived from the Latin saying Divide et impera)
When we start thinking to divide our project in layers, we should start from the project, and we have to ask about the best way to support such operational requirements as maintainability, reusability, scalability, robustness, and security, it's important to reconcile the following forces within the context of current environment that will be used. Every developer should think in Separation of concerns among components such as separating of the user interface from the business logic, and separating of the business logic from the database, and this will increases flexibility, maintainability, and scalability, the reuse of components by multiple applications. 
Separate the components of your solution into layers :
The best way in layered approach constraints components in one layer to interact only with peers and with the layer directly below. A relaxed layered application loosens the constraints such that a component can interact with components from any lower layer. Layers work together to produce the completed application, group of code working together as a common concern.
Let's revisits the classic 3-tier architecture
 
Presentation Layer : it contains the user oriented functionality responsible for managing user interaction with the system, and generally consists of components that provide a common bridge into the core business logic encapsulated in the business layer.
Business Layer : it implements the business logic of the solution and the core functionality of the system, and encapsulates the relevant business logic. It generally consists of components, some of which may expose service interfaces that other callers can use.
Data access Layer :  it encapsulates the code that accesses the persistent data stores such as a relational database, it provides access to data hosted within the boundaries of the system, and data exposed by other networked systems; perhaps accessed through services. The data layer exposes generic interfaces that the components in the business layer can consume.
Designing for scalability
Scalability is the capability if a system to handle a growing amount of work. Although usage is minimal during site development, usage can increase greatly after implementation to a production. To ensure a positive user experience, you need to consider scalability early in the application planning phase because your scalability decisions affect the architecture design considerations.
Move to n-tier architecture (.NET implementation)
"ASP.NET MVC framework provides a certain level of separation of concerns by breaking the application responsibilities down into models, views and controllers."
Business Layer can be divided to : Domain layer and Application layer.
Domain layer : will contain models and services, application layer will interacts with presentation and domain layers.

Infrastructure layer will contain IoC, cache and repositories, these components will be used by Business layer.
Business Logic—Domain-driven design Definition
Application layer : this layer will depend on use-cases : Data transfer objects, Application services that will call only methods implemented in Domain Layer.
Domain Layer : this layer will contain domain model (object-oriented entity, model functional model)  and domain services that is the implementation of every treatment so it's invariant to use-cases.
Go further : next post !

jeudi 3 mars 2016

Cutting Edge - Command and Query Responsibility Segregation for the Common Application


When we decide to start any project, we have to think about the architecture, and before using any pattern, we attempt to improve upon the stereotypical architecture in small rational steps while trying to minimize the cost in terms of productivity for each step towards a better architecture. 
Domain-Driven Design (DDD) is used about a decade ago, inspiring software developers and architects, we can get more details about this approach from this link : http://www-public.tem-tsp.eu/~gibson/Teaching/CSC7322/ReadingMaterial/Evans03.pdf  written by Eric Evans and this book http://dddcommunity.org/book/evans_2003/  where you can get answers in ways of making the design of your software independently from your problem and your project, it let you realize your dream of building applications around a comprehensive object model to address all stakeholder requirements and concerns, because it's old, we find an important strategic concept of DDD called Bounded Context. (http://martinfowler.com/bliki/BoundedContext.html
Recently, another method with new acronym started gaining scale,it is not a pattern like DDD but it's a concept  built on DDD called Command and Query Responsibility Segregation (CQRS). The fundamental aspect of a CQRS solution is the separation between the command stack and query stack.
In CQRS, The command stack is concerned only about the performance of tasks that modify the state of the application, each stack is designed separately; such a distinct design potentially can lead to having two distinct domain layers and even two distinct databases. As usual, the application layer receives requests from the presentation and orchestrates their execution. 
But, can we  consider CQRS a rework of the classic multi-layered architecture that leaves the door open for more changes and evolution ?
If we start using CQRS, you will not find the need to have a distinct section of the domain layer for just reading data. Plain queries out of ready-made tables are all you need. How ? The query stack is concerned with data retrieval, it uses a data model that matches the data used in the presentation layer as closely as possible, so, it performs read-only operations against te back end that don't alter the state of the system. In the implementation of a modern query stack, the LINQ language in Microsoft .NET framework is helpful. So, we suppose that you have a  ASP.NET MVC Web application that select a list of clients data to display in different forms, our system is organized in layers. and the application services invoked directly from controllers that orchestrate use cases. We consider the application layer as platform from which you run commands and queries against the rest of the system, so if you try to apply CQRS, so ,we will use two distinct middle tiers, first one takes care of commands that alter the system state and the other retrieves the data.
In this case, you have  created a couple of class library projects—query stack and command stack—and reference both from the main Web server project.