Skip to main content

Posts

When DDD may be overkill or should be avoided?

  1) Simple CRUD or data-centric systems If the core problem is straightforward data storage and retrieval with minimal business rules: Admin dashboards Basic inventory apps Simple reporting tools DDD adds layers (aggregates, repositories, domain services) without real benefit. 👉 Better fit: Transaction scripts, layered architecture, or even low-code. 2) Stable domains with little change DDD shines when: Rules change frequently Language evolves Domain knowledge deepens If the domain is mature and unlikely to change (e.g., fixed regulatory forms, static catalogs), DDD’s modeling effort doesn’t pay off. 3) Small teams or short-lived projects DDD requires: Shared language Modeling workshops Ongoing refinement For: 1–2 developers Proof-of-concepts Hackathons MVPs with uncertain future …the coordination cost exceeds value. 4) When the domain complexity is low but technical complexity is high Example: Real-time streaming...
Post a Comment
Read more

How DDD works in an agentic-AI development lifecycle?

Scenario Build an Order Management system with: order lifecycle payments shipment cancellations refunds We’ll map roles → inputs → artifacts → outputs → consumers . 1) Roles in AI-era DDD We’ll use these roles: Architect Domain Designer Developer AI Coding Agent QA / Validator AI 2) Step-by-step lifecycle with artifacts Step 1 — Architect defines domain boundaries Architect input business scope enterprise architecture system landscape integration needs Architect produces Bounded Context Map Example: Order Management Payment Shipping Customer Catalog Relationships: Order → uses Payment Order → triggers Shipping Order → reads Catalog Who consumes Domain Designer AI Agent Developers 👉 This tells AI: “don’t mix payment logic into order.” Step 2 — Domain Designer defines ubiquitous language Designer input workshops with business policies terminology lifecycle rules Designer produces Domain Glossary Example: Order: co...
Post a Comment
Read more

NFRs and how to tackle them?

1. Decision Framework for NFRs Here’s a step-by-step process you can follow: Elicit and quantify the quality attributes / NFRs Gather from stakeholders (business, operations, security, compliance) what qualities they need: e.g., “system must respond within 2 seconds 95% of time”, “uptime 99.9%”, “must support 1000 concurrent users”, “must be maintainable by small team for 10+ years”, etc. For each NFR, aim for a measurable target (so you can trade-off). Use a structured taxonomy: e.g., from ISO/IEC 25010:2011: reliability, performance efficiency, security, maintainability, portability etc. jageshwartripathi.blogspot.com Assess constraints and context What is the environment? (Bare-metal, K8s on OpenStack, VMware Cloud) — you know your deployment scenarios. What is legacy/obsolescence risk? What existing systems are you integrating with? What is the budget/time-to-market? What organisational capabilities (DevOps, SRE, monitoring) are in place? What regulato...
Post a Comment
Read more

Example 9: ArchiMate serving relationships in various layers and across layers

 Diagram: Code: @startuml !include <archimate/Archimate> <style> element {     HorizontalAlignment: left;     MinimumWidth: 180;     Padding: 20; } note {     BackgroundColor: #FFFFCC;     RoundCorner: 5;     MaximumWidth: 250; } </style> left to right direction title "ArchiMate 3.2 Valid Serving Relationships" ' Strategy Layer Serving Relationships rectangle "Strategy Layer Serving" {     Strategy_Capability(cap1, "Capability 1")     Strategy_Capability(cap2, "Capability 2")     Rel_Serving(cap1, cap2, "serves")     note on link         Capability serving another         Capability     end note } ' Business Layer Serving Relationships rectangle "Business Layer Serving" {     Business_Service(bs1, "Customer Service")     Business_Process(bp1, "Fulfill Customer Request")     Rel_Serving(b...
Post a Comment
Read more

Example 8: ArchiMate triggering relationships in various layers and across layers

  Diagram: Code: @startuml !include <archimate/Archimate> <style> element {     HorizontalAlignment: left;     MinimumWidth: 180;     Padding: 20; } note {     BackgroundColor: #FFFFCC;     RoundCorner: 5;     MaximumWidth: 250; } </style> left to right direction title "ArchiMate 3.2 Valid Triggering Relationships" ' Business Layer Triggering Relationships rectangle "Business Layer Triggering" {     Business_Event(be1, "Order Received")     Business_Process(bp1, "Process Order")     Rel_Triggering(be1, bp1, "triggers")     note on link         Event triggering a Process         (most common pattern)     end note          Business_Process(bp2, "Validate Order")     Business_Process(bp3, "Fulfill Order")     Rel_Triggering(bp2, bp3, "triggers")     note on link ...
Post a Comment
Read more

Examples 7: ArchiMate flow relationship between elements in layers

Diagram Code @startuml !include < archimate / Archimate > < style > element {     HorizontalAlignment : left ;     MinimumWidth : 180 ;     Padding : 20 ; } note {     BackgroundColor : #FFFFCC ;     RoundCorner : 5 ;     MaximumWidth : 250 ; } </ style > title "ArchiMate 3.2 Valid Flow Relationships" left to right direction ' Business Layer Flow Relationships rectangle "Business Layer Flows" {     Business_Process ( bp1 , "Order Process" )     Business_Process ( bp2 , "Payment Process" )     Rel_Flow ( bp1 , bp2 , "Order data" )     note on link         Flow between Business Processes     end note         Business_Function ( bf1 , "Sales Function" )     Business_Function ( bf2 , "Delivery Function" )     Rel_Flow ( bf1 , bf2 , "Sales information" )     note on link     ...
Post a Comment
Read more