Posts

Microservice & Domain Driven Design

Image
  Define Domain Boundary for Microservice Identifying domain model boundaries for each microservice is a crucial step in designing a microservices architecture. It helps in organizing the system into distinct services that are modular, scalable, and maintainable. Here are general steps and considerations for identifying these boundaries: 1. Understand the Business Domain Domain Analysis : Start by understanding the business domain. Identify the key entities, their relationships, and the business processes that involve these entities. This understanding will guide the segregation of services. Business Capabilities : List down the core capabilities your application needs to provide. These capabilities often hint at potential service boundaries. 2. Domain-Driven Design (DDD) Bounded Contexts : Use Domain-Driven Design principles to define bounded contexts. A bounded context is a specific responsibility or function within the domain

Hybrid Model for Monorepo and Polyrepo

Mix of Monorepo and Polyrepo in an Organization Hybrid repository strategies combine elements of both monorepo and polyrepo approaches to take advantage of their respective strengths while mitigating their weaknesses. Here are some strategies for adopting a hybrid approach: Monorepo for Core Shared Code : Use a monorepo for shared libraries, common components, and infrastructure code that are critical across various projects. This approach ensures consistent versioning and easy code sharing for foundational components. Polyrepo for Project-Specific Code : Create separate repositories for project-specific code, applications, or services. Each project's repository contains its own codebase, dependencies, and version control, providing autonomy for project teams. Dependency Management : Establish a clear and well-documented process for managing dependencies between the monorepo

Agile Model - The Agile Fluency Model

Image
The Agile Fluency Model is an agile model that leaders of an organization can use to make decision in agile adoption, the investment needed to ensure project teams are actually agile, and to understand some other strategic factors that can affect the success/failure of an agile project or project team. Further details can be found at  The Agile Fluency Model The picture below represents my understanding about the Agile Fluency Model. Each layers in the model requires a different level of experience in software engineering activities. The longer a person stays in the field, the higher level that person can venture into. Diagram 1: My understanding about the Agile Fluency Model