{
  "id": 10361814,
  "title": "Day 23 - Domain-Driven Design - কোড যখন Business-এর ভাষায় কথা বলে",
  "url": "https://urgent.news/2026/09/28/day-23-domain-driven-design-business",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-28T04:20:00.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/mislam-dev/day-23-domain-driven-design-kodd-ykhn-business-er-bhaassaay-kthaa-ble-106a"
  },
  "original_language": "en",
  "account": "Day 23 - Domain-Driven Design - Code Speaking Business Language\n\nAs applications have grown in size, developers have been working with microservices or modular monoliths. Everything seems to be running smoothly, but a new issue has surfaced. During a business team meeting, they mentioned that when a VIP customer confirms an order, the loyalty points need to be added and inventory stock reserved. However, the codebase does not have any references to VIP customers or loyalty points. Instead, there is a UserEntity, status_flag = 1, and an OrderRepository. The language used by business teams differs significantly from the code's language. This gap often leads to bugs and misinterpretation of requirements in complex projects. Domain-Driven Design (DDD) provides a solution to this problem.\n\nDDD is an approach to software development where business domain or business logic is given more importance than the database or framework. Typically, developers start coding with databases or frameworks (Data-Driven). However, in DDD, the focus is first on understanding the business tasks (Domain), and then the code is organized accordingly. The main goal is to eliminate the distance between developers and the domain experts (business team) and structure the code in a way that it aligns with the real-world business process.\n\nThe first rule of DDD is to speak the same language. Developers and business stakeholders should use the same terms. If business says \"confirm order,\" there should be an \"order.confirm()\" method in the codebase. If business refers to \"customer,\" the code should use \"Customer\" instead of \"User.\" This common vocabulary is called Ubiquitous Language. When code and business speak the same language, implementing requirements becomes much easier.\n\nBounded Context: In a large system, the same word can have different meanings in different contexts. In the sales context, a customer may be defined by name, contact, and purchase history. In the shipping context, a customer may be defined by delivery address and preferred time. In the support context, a customer may be defined by ticket history and complaint log. These are different Bounded Contexts. Each context has a slightly different model of the Customer. If this is not understood, it can lead to the creation of a God-object, which is a massive User class containing logic for all contexts.\n\nMicroservices often use Bounded Contexts to divide services. In a bounded context, Entity and Value Object are the two types of objects that handle data. An Entity has a unique ID and can change its state over time, such as an Order or a Customer. Its ID remains the same even if its properties change. Value Objects do not have an ID and are identified by their values, such as Address or Money. Value objects are always immutable.\n\nAn Aggregate is a cluster of objects (Entities and Value Objects) that must be consistent together. For example, an Order can be an Aggregate, containing OrderItems and ShippingAddress (a Value Object). No other class can modify an OrderItem directly; it must be done through the Order. Domain rules must be implemented within the code, not in services or controllers. Domain Events are emitted when a state change occurs in an Aggregate. Event-Driven Architecture (EDA) works seamlessly with these events. When an Order is confirmed, an OrderConfirmedEvent is fired. Other modules can independently handle this event, such as sending emails or updating inventory.\n\nThe Repository Pattern separates the data access layer from the domain layer. The domain layer remains pure, without any dependencies on frameworks. In the domain layer, there is an interface defining the order repository, and the implementation resides in the infrastructure layer.",
  "summary": "আপনার application এখন অনেক বড় হয়েছে। আপনি microservices বা modular monolith নিয়ে কাজ করছেন। সবকিছু ঠিকঠাকই চলছে, কিন্তু নতুন একটা সমস্যা দেখা দিলো। Business team মিটিংয়ে বলছে, \"যখন কোনো VIP Customer-এর Order confirm হবে, তখন তার Loyalty Points add করতে হবে এবং Inventory থেকে Stock reserve করতে হবে।\" কিন্তু আপনার codebase-এ গিয়ে দেখলেন VIP Customer বা Loyalty Points নামে কিছুই নেই! সেখানে আছে…",
  "key_points": [
    "Domain-Driven Design (DDD) aligns business language with code to prevent bugs.",
    "Bounded Contexts define different models of the same entity (like Customer) across system domains."
  ],
  "editors_take": "Domain-Driven Design bridges the gap between business and code by prioritizing business logic, fostering a common vocabulary, and aligning code with real-world processes, making requirements implementation easier and reducing bugs.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}