Over view of software artitecture
Download as PPTX, PDF5 likes482 views
The document discusses various software architecture patterns and principles, comparing monolithic and microservices architectures. It covers topics like layers, domain-driven design, code-first versus database-first approaches, and considerations for data management in multi-tenant systems. The key aspects of architectures like microservices and domain-driven design are explained at a high level.
![ 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](https://image.slidesharecdn.com/overviewofsoftwareartitecture-170722184107/85/Over-view-of-software-artitecture-62-320.jpg)
Over view of software artitecture
- 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.