When a company will initiate the development of an information system for its business, they are sometimes faced with several offers from vendors. The aspect that is usually in the spotlight is the high cost that must be incurred for a software development project, but they are not sure whether the software that is built later is really appropriate for business goals. In information systems management, this is referred to as waste. Some of the factors that cause this waste are:
- Needs analysis stage that was not executed properly
- The analysis and design phase is too large and exceeds the expectations of the company’s needs
The two factors above can cause software development to become unfocused, take longer, the costs incurred are greater and often the software that is built cannot meet the needs of the company.
Get to know Domain Driven Design
One approach to be able to avoid the possibility above is to apply a way of analyzing problems and finding solutions in a smaller and detailed scope but still looking at your company’s business software in a broad perspective. At Meta Lab we apply Domain Driven Design (DDD) practices in the development of an information system.
Domain-Driven Design (DDD) is an approach to developing complex software that links core business concepts and technical implementations in depth. DDD is not a methodology or technology, but rather a practice and terminology approach that focuses on software design decisions and accelerates software projects related to complex business domains.
What Are The Advantages of Using The DDD Approach?
The advantages of using the DDD approach for companies and information system developers are :
- Equating perceptions, language, terms and even ways of thinking between the development team and business analysts,
- Provide the opportunity for the development team and business to give each other advice in system development,
- Eliminate the boundaries between business and technical.
The above advantages sound familiar with some system building methods, right? Yes, DDD is very often used in building information systems using Agile methods or implementing DevOps in an enterprise.
Meta Lab uses this approach to ensure that complex systems designed can be delivered quickly and focused on every business domain requirement. What does it mean? Your company can ask Meta Lab to design and build your system according to the company’s needs and budget, with a guarantee that your system can grow and add easily if needed. If your company is in a tight financial constraint but wants to build a system for a line of business, you and our developer team can continue to build applications that run as needed, concise, fast and can still be developed or integrated with other applications in the future. This is what we call the “Start Small, Go Big Easier” philosophy.
This is what we call the “Start Small, Go Big Easier” philosophy.
How is DDD in practice?
Before starting the technical conversation (that’s also better left to the Meta Lab team), it’s a good idea to start by understanding some of the following terms or concepts.
Domain Model
Domain model is a way to represent reality by abstracting what aspects are needed or what is in the context of a particular domain. Another example of an explanation of the domain model is that when creating a system, you want the software to facilitate user activities, right? The area that relates to user activity or interest in the use of software is the domain model. The domain model is structured and selective on the representation of knowledge, depending on the vision of the software being created.
For example, in a system of buying and selling goods in e-commerce, the user’s business process in buying goods involves several groups of work, namely searching and viewing a list of goods, adding to the basket, choosing a method of delivery of goods and making payments.
The system built will not be simple because each of the above activities involves large and diverse data, it may require external data and even use services from other systems or applications. Therefore, from the DDD point of view, system architects usually divide it into at least 4 domains, namely the domain of Inventory, Cart, Billing and Shipping.
Bounded Context
Bounded Context is an approach that separates large models into smaller contexts explicitly and the relationship between them.
With this concept, the business analyst team will be divided into several small teams, each led by a domain expert. Each team will focus on identifying and analyzing business processes and their accompanying components while still paying attention to the ease of exchanging data and information between domains.
With Bounded Context, you don’t have to worry about differences in vocabulary or differences in scientific concepts used in software development. For example, the concepts of bookkeeping and financial accounting have similar vocabularies, or the concepts of sales and support have different behaviors. This is due to the application of Ubiquotus Language in the DDD approach.
Continued to the second part of the article.
