What’s a Domain-Driven-Design approach?

DDD gives you both the strategic and tactical modeling tools necessary to design high-quality software that meets core business objectives and that allow to:

• Put domain experts and developers on a level playing field, which produces software that makes perfect sense to the business, not just the coders.</span
• Making software that is as close as possible to what the business leaders and experts would create if they were the coders.
• The design is the code, and the code is the design.

To know more, I invite you to read « Implementing Domain-Driven Design » book from Vaughn Vernon.

Freeduse technology is DD based… How?

The Freeduse architecture model is based on a Domain-Driven-Design approach. Each main can be supported by one dedicated application and sub-domain can be specifically managed by one or many applications.

An application which supports a domain or a sub-domain can include an User Interface Layer, an Application Layer and a Domain Layer. It can use an Infrastructure Layer through proxy design pattern.

The components of infrastructure layer can be shared (in terms of use) between several applications.

Domain Layers Structuration

The Information System includes several layers. Each domain context can include one or many components distributed in User Interface Layer, Application Layer, Domain Layer and/or Infrastructure Layer.

• User Interface Layer: regarding the direct point of contact with the user/beneficiary of a business process. Layer implemented by GUI delivered to user through interactive applications.
• Application Layer: include Application, Process & Orchestration and Services layers. Include business logic about the processes performed by the IT system.
• Domain Layer: concerning the business data and rules of management of status.
• Infrastructure Layer: regarding the layers Data Services & Messaging, Data Abstraction and transversal SOA areas (Security & Access Control, Integration Middleware).

Freeduse context is under control

The dependencies between the domains is managed through functional interfaces to maintain a good level of isolation that allow exposure to change without big impact regarding the systems coupling.

How to maintain a flexible integration between bounded contexts?

Each context include a dedicated sub-service dedicated to each sub-domain. When a dependency is managed by a context to another one, a translator pattern is required for interpretation of the published language used by the context in dependency. For isolation between contexts, each one use an adapter pattern for integration with the client facade of another context.

Freeduse develops an elegant architecture of the systems

Each domain service is supported by an independent component which can be deployed in standalone lifecycle and which manage the dependencies with other components like specified by the contexts integration model. The internal components of an application are called micro-services which implement the business processes regarding the domain context.

A global registry allows the discovery of systems to link the context with dynamics approach (at runtime).

Several main systems are implemented to be deployed in Internet platform and/or to be embedded into a product.

The packaging strategy applied on the project provides all the systems ready for execution into the physical infrastructures which are mainly smartphone of a customer, micro-controller installed into a product, Internet platform.

So Why Freeduse is investing in DDD?

The founders of Freeduse have a large experiences in the build of software architectures created for several companies since 20 years, and selected Domain-Driven-Design to create this new technology because:

• Brings domain experts and Freeduse developers together in order to develop solution that reflects the mental model of the business experts (the product manufacturers and retailers who know their markets and their customer’s usage cases).
• It helps define the best inter-team organizational relationships and provides early-warning systems for recognizing when a given relationship could cause software and even project failure. The technical aspects of strategic design have the goal of cleanly bounding systems dedicated per Industry vertical and business concerns, which protects each business-level service.
• This approach meets the real technical demands of the software by using tactical design modeling tools to analyze and develop the executable software deliverables (correct codification of the domain expert’s mental model, highly testable, scalable and allows for distributed computing).

Freeduse uses this approach with his partners to succeed in delivering true business value to their final users.

So, join the Freeduse experience!