Presentation given in softxpert on July 2017

3.  “Architecture represents the significant
design decisions that shape the system”
 - How it works
 - How to build it
 Architecture is :
 High level
 Layers
 Components
 Relationship

4.  Reason about change as system grows
 Better way to make the hardest design
decisions
 Helps you estimate cost and schedule
 Better communication among all stockholders
 Better quality
 Q : What is the difference between
Architecture and design ??

8. Messy Architecture is
◦ Complex
◦ Incoherent
◦ Rigid
◦ Untestable
◦ Unmaintainable
◦ Changing a part here
and it breaks a part
over there
◦ The architecture
fights you each step
of the way
Good Architecture
◦ Understandable
◦ Coherent
◦ Flexible
◦ Testable
◦ Maintainable
◦ Extendable
◦ It helps you evolving
the system each step
of the way

9.  Ask the important question and take the
biggest decisions
 Devise the big picture
 Evaluate the architecture
 Evolve the architecture
 Sell / communicate the architecture
 Guard the architecture, how ?

12. It’s standard practice to build enterprise apps in layers:
• each layer has its own set of responsibilities,
providing a separation of concerns.
• Layers is about code organization at development
time
• Layers should be testable individually
• Low coupling between layers and high cohesion
between them is needed
• Business logic layer contains NO user interface code
and shouldn’t refer to UI modules or code
• No circular dependency between layers
• Layers should be shy about their internals
• Types of layers :

20.  Strict : Each layer can use only API offered by
ONE layer beneath it (virtual machine)
 Relaxed : Each layer may use API offered by
any layer beneath it
 What’s a circular dependency ??

22.  Service layer is the middle layer It abstracts business logic
and data access. The idea behind such a layer is :
1) to have an architecture which can support multiple
presentation layers such as web, mobile
2) specify transaction behavior so if you have calls to multiple data
access objects you can specify that they occur within the same
transaction
3) if you have a complex architecture
Typically you will have services that encompass use cases for a single
type of user, each method on the service is a single action (work to be
done in a single request-response cycle) that that user would be
performing

24. • Do not put presentation specific logic within
your models or domain objects
• Do not put logic within your pages and
controllers, i.e., logic to save objects to the
database, create database connections etc,
which will make your presentation layer
brittle and difficult to test
• If you are using MVC for ui , then use thin
controller

25.  Maintainable
 Testable
 Easy to assign separate "roles"
 Easy to update and enhance layers separately

26.  New applications that need to be built quickly
 Teams with inexperienced developers who
don’t understand other architectures yet
 Applications requiring strict maintainability
and testability standards

33.  Large team
It's hard to get face-to-face communication, so you want to
decouple the read models from the write-side of things
(sagas, domain, CRUD)
 Scalability matters
With CQRS you can achieve great read and write performance.
Command handling can be scaled out on multiple nodes. And
as queries are read only operations they can be optimized to
do fast read operations.
 Situation that need event sourcing
When you have a complex or hard business domain and: with
event sourcing; you want to prove your behaviors through
testing and reasoning

34.  Problem to think about :
 There is an ecommerce store that has a web
catalog to get the items and it’s description ,
then the user can purchase any of the items
in the catalog . Finally the admin can see
sales statistics how to do that using CQRS ???

38.  A monolithic application describes a single-
tiered software application in which the user
interface and data access code are combined
into a single program from a single platform.
A monolithic application is self-contained,
and independent from other
computing applications.

39. Now I am Hungry 

44.  “Micro-services architectural style defines a
setup, where application components are
standalone applications of their own. These
independent application components talk to each
other either using a protocol”
 While designing systems in microservices
architecture, we should be identifying
independent components/modules appropriately.
These components will be mini applications,
which will be developed separately. They will
follow their own development and deployment
lifecycle.

46. 1. Modularity
Decentralization is an important aspect from
the beginning of any project.
2. High Traffic
The application in focus will have high volume
transaction or traffic.
3. Availability and scalability Matters
4. Different technologies.

47. 1. Isolation is needed
Part of your functionality needs to be developed in
mostly full isolation by a different dev/team than your
main app.
2. Same service in multiple applications
Part of your functionality will be used across multiple
applications, and this includes domain state not
just code(if it's just code, you could just share it
between apps as a library, via Composer or otherwise).
3. Distributed teams
4. Long term projects

48.  Consider we are developing one school management system.
1. In a school management system we have various important
components like student registration, attendance, fees,
assessments, etc.
2. When we develop this application using microservices
architecture we will have independently deployed mini
applications for student registration, attendance, fees and other
modules.
3. In a general setup we can have scenarios where we need data
from various components for a single request. Ideally, we will
have a API gateway or front controller which will aggregate data
from these components and give it back.
4. We should have inter-component communication. Components
can communicate over REST APIs or Messaging or RMI (Remote
Method Invocation).

51.  In theory, a client could make requests to each of the
microservices directly. Each microservice would have a
public endpoint (https://serviceName.api.company.name).
This URL would map to the microservice’s load balancer,
which distributes requests across the available instances.
To retrieve the product details, the mobile client would
make requests to each of the services
 Drawback with this approach is that it makes it difficult to
refactor the microservices. Over time we might want to
change how the system is partitioned into services. For
example, we might merge two services or split a service
into two or more services. If, however, clients
communicate directly with the services, then performing
this kind of refactoring can be extremely difficult.

52.  The API Gateway is responsible for :
 Routing
 request routing, composition, and protocol translation. All
requests from clients first go through the API Gateway. It
then routes requests to the appropriate micro-service. The
API Gateway will often handle a request by invoking
multiple micro-services and aggregating the results. It can
translate between web protocols such as HTTP and Web
Socket and web-unfriendly protocols that are used
internally.
 Monitoring
 Caching
 Handling partial failures
More : https://www.nginx.com/blog/building-
microservices-using-an-api-gateway/

53.  Let’s imagine that you are building an e-
commerce application that takes orders from
customers, verifies inventory and available
credit, and ships them. The application
consists of several components including the
Store FrontUI, which implements the user
interface, along with some backend services
for checking credit, maintaining inventory
and shipping orders.

54. Micro services Monolithic
1. Partial
deployment/upgrades
2. Better availability as
the system wont all
crash at once
3. Multiple platform
4. maintainability
1. Simplicity
2. Consistency .

56. Q1 - Why would a micro-services architecture
be beneficial ?
A. Few services can be deployed and upgraded
without a rebuild of other functioning services.
B. Less service interruption
C. Different parts of a development team can
manage individual parts of a microservice.
D. All of the above.
E. None of the above.

57.  Q2 - Adding a new layer in a layered
application to improve testability will also
negatively affect :
A – Performance
B – Security
C – Maintainability
D - Modificationability

58. Q3 - Why would micro-services not be
beneficial?
A. No need to separate the reading and writing
operations to the data store.
B. Members of a development team aren't as
knowledgeable.
C. All of the above.
D. None of the above

59. Q4 - Hence the name, micro-services is meant
for smaller businesses
A. True
B. False

60.  Q5 – A system for a nuclear power unit is
recording important factors such as
temperature, pressure, ..etc. each 30 seconds
for many equipment's used in the unit. Yet it
also must get an updated reading for the
current state of any equipment which pattern
you could recommend for such a system
:
A– Micro-services with API Gateway
B – CQRS with Event sourcing
C- N tiers with service layer
D –None of the above

62.  Domain-driven design (DDD) is an approach
to software development for complex needs by
connecting the implementation to an evolving
model.[1] The premise of domain-driven design is
the following:
 Placing the project's primary focus on the
core domain and domain logic Not the database
 initiating a creative collaboration between
technical and domain experts to iteratively refine
a conceptual model that addresses particular
domain problems.
The term was coined by Eric Evans in his book of
the same title

69.  Domain is essential
 Use case is essential
 UI is detail (Mvc, JS single page
application,..etc)
 Persistence layer is a detail (RDBMS, No
SQL,..etc)

70.  ‘The Code First approach provides an
alternative to the well-known Database
First approach. As far as I know, it comes from
the Microsoft world, but it does not really
matter.
 Using a Database First approach, you design
your database schema, and then generate your
classes.
 The Code First approach basically, start by
writing your classes, think in term of objects,
not tables. Then from the domain code the
database is then generated!

71. 1. Presentation layer
2. Application layer
The application layer is responsible for driving the workflow of the
application, matching the use cases at hand. These operatios are
interface-independent and can be both . his layer is well suited for
spanning transactions, high-level logging and security.
3. Domain layer
The domain layer is the heart of the software, and this is where the
interesting stuff happens. There is one package per aggregate, and to
each aggregate belongs entities, value objects, domain events, a
repository interface and sometimes factories
4. Infrastructure layer
it supports all of the three layers in different ways, facilitating
communication between the layers. In simple terms, the infrastructure
consists of everything that exists independently of our application:
external libraries, database engine, application server, messaging
backend and so on.
Project by DDD http://dddsample.sourceforge.net/architecture.html

74. :
 http://williamdurand.fr/2013/08/07/ddd-
with-symfony2-folder-structure-and-code-
first/
 http://williamdurand.fr/2013/08/20/ddd-
with-symfony2-making-things-clear/
And This Book if you have time!

76. ….
• Data Management
1.Type of data store
2.Single tenant or multiple tenant and why ?
3. Size of the request
4. How long you want to keep the data?
5. Storage space
6.Query rate (worst case)
7.Data access model
8.Code first vs database first
9.What else ?

78.  There are some reasons why you would want a separate database per
client:
 he design pattern that a multi-tenant application developer chooses
typically is based on a consideration of the following factors:
• Ownership of tenant data. (isolation) An application in which tenants
retain ownership of their own data favors the pattern of a single
database per tenant.
• Scale. An application that targets hundreds of thousands or millions of
tenants favors database sharing approaches
• Value and business model. If an application’s per-tenant revenue if small
(less than a dollar), isolation requirements become less critical and a
shared database makes sense. If per-tenant revenue is a few dollars or
more, a database-per-tenant model is more feasible. It might help
reduce development costs.
 However, I think the default should be one database because of
maintainability and consistency.

79.  https://techbeacon.com/top-5-software-
architecture-patterns-how-make-right-
choice
 https://en.wikipedia.org/wiki/List_of_softwar
e_architecture_styles_and_patterns