Showing posts with label architecture. Show all posts
Showing posts with label architecture. Show all posts

Sunday, August 19, 2018

Domain Driven Design - What is it and why

What is DDD?

In very simple terms DDD is about making your software as a model of a real world system or a process. When practicing DDD you'll work with a domain expert to build a ubiquitous language (UL). UL is a conceptual description of the system. UL is written down in such a way that domain expert should be able to understand and verify the UL is correct.

UL will include words that is used in actual domain. UL forms the basis of the OO design. DDD will have  following object categories
  • Value objects
  • Entities
  • Aggregate roots 

Recommended patterns for DDD
  • Repository 
  • Factory
  • Service

When not to use DDD (airbrake)

DDD is not suitable for projects where requirements and domain expertise is less. DDD sometimes goes in as an iteration which may not be suited for some projects. It may not be suited for projects which involves high technical complexity as opposed to domain complexity as well. 





Notes

https://stackoverflow.com/questions/1222392/can-someone-explain-domain-driven-design-ddd-in-plain-english-please/1222488#1222488

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice

https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/net-core-microservice-domain-model



Tuesday, February 7, 2017

Software Architecture Design - Considerations

Image Credits  : Colour Box


Architecture of anything defines how well the thing is designed and how long it's going to last. Be it a a building, a car or anything the same rule applies. It is the same when it comes to a software architecture as well.

If the architecture of a software is designed well, it should be able to accommodate any or many of the requirements be it functional or non-functional, the stakeholders requests. Therefore when designing a good architecture, one should be very careful when laying the foundation.

Keep in mind the following non-functional requirements when you're designing the initial architecture of your application.

Scalability


High Scalability has many practical case studies. It is important to keep in mind how much scalable your application is going to be in coming milestones. Size of codebase also matters

  • Scale up (Increase power of hardware)
  • Scale out  (Increase no. of hardware)
Scalability of Django. This video demonstrate how Instagram scales.

Instagram has a caching(memcache) mechanism between database and the client. Whenever user is served it keeps it in the cache as well as update primary and secondary storage.



Read What is scalability for more information


Performance

This is a key fact when the application grows larger. This might not matter initially but it should be kept in mind as the application grows. Some considerations for performance are,

  • Perceived performance (Fluent Conf 2017 - Video)  : Measure of How Quick a User Thinks Your Site Is. 
    • If you look at some websites it first loads the content placeholders which is mainly html and then only loads the actual data which takes time
    • Applicable for mobile apps as well. First loads the placeholder before loading data from server
  • Bundle & minification : Reduces the size of files that needs to be downloaded
  • Caching & content delivery networks
  • Optimizing image usage

Web Performance: Leveraging the Metrics that Most Affect User Experience (Google I/O '17)

Re-usability

Make sure to design common things in such a way that they can be reusable.

Supportability

What devices is your application going to support in future? Can the architecture be designed in a way that it supports future requirements of new devices?

See - Azure Design Guideline

There are lot of other things which should be considered when designing an architecture. But most importantly,

"make sure to think through cost and the benefit for every decision you make."

Thursday, January 12, 2017

Microservices what is it really

Image Credit : Contentful

Microservices is a architectural pattern where a structure of an application is decomposed as collection of loosely coupled services. These services are responsible for handling separate business capabilities.

Microservices helps software teams to continuously deliver large scale complex application in pieces. (Should you use microservices)

We all can search and find theories of microservices, but practical use cases and practical issues are what most of us will be interested in espeically when such resources are rare. So I thought of organizing this page to list some concerns involved.

Image Credits : Bhagwati Malav (via. Medium)

Problems with Monolithic Architecture

Traditionally monolithic architecture is used for many software's but it generates bigger problems with time.

  • Involves a single code base which increases code complexity, learning curve, maintainability, dependencies
  • Overloads IDE since there's only single code base
  • Difficult continuous integration since all application is a single one
  • Scaling is linear. Since there is no modularity all modules comes as a single package. Cannot scale different modules separately based on the requirement (Even if module A gets used 99% and B 1% both will be handled via. same infrastructure) 
For smaller teams most of the time monolithic will be the way to go. Consider microservices if you  have previous experience but not because you want to try it. If your application tends to get bigger , much complex or if you encounter a non-functional business requirement such as one part of the application need higher performance consider using microservices. This is because separate services can scale independently. Note that what can be done in monolithic can be done in microservices as well.

Patterns in Microservices

There are patterns which can be used with Microservices.

API Gateway (source)

There could be requirements from front-end to have an API which would access multiple microservices to retrieve data. Solution here is to create a separate API Gateway which would access required microservices and give what you need. 

API Composer is when you need to query multiple services where services uses Database per service pattern. API Gateway often does API composition as well. 


Microservices in Azure - Service Fabric

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices
https://azure.microsoft.com/en-us/blog/microservices-an-application-revolution-powered-by-the-cloud/
https://docs.microsoft.com/en-us/azure/service-fabric/

Case studies
https://blogs.msdn.microsoft.com/azureservicefabric/tag/case-study/

Authentication in Microservices

https://stackoverflow.com/questions/29644916/microservice-authentication-strategy

Microservices - Case Studies






Monday, October 8, 2012

Powered by Blogger.


Software Architect at Surge Global/ Certified Scrum Master

Experienced in Product Design, Software Engineering, Team management and Practicing Agile methodologies.

Search This Blog

Facebook