Why DDD matters?

GoF Design Pattern, EIP, Refactoring, P of EAA, etc. Their concept is to solve technical problems through technical means, but not fundamentally solve business problems.

DDD is an architectural idea that really solves a business problem:

  • Business and technology decoupling
    • Control software complexity
    • Avoid confusing the complexity of the business logic with the complexity of the technical implementation because they vary in different dimensions
    • Centralizing business logic at domain level enables product and r&d to have a common code exchange site
  • Unified and consistent domain modeling and code implementation
    • The analysis model and the design model are no longer separated
    • A domain-centered layered architecture, with technical means to isolate by reversing dependencies
  • Change the pastService + databaseTechnology-driven development patterns
    • Back to business nature, the code has stronger business expression
    • Precipitate models that reflect domain knowledge and focus on key concepts
    • Free r & D productivity, no longer tied hands, can give full play to the advantages of object-oriented writing business code
  • Unified language, high code business expression ability

Domain Driven Design (DDD) is about mapping business domain concepts into software artifacts.

Why is DDD hard to land?

Because DDD is not a set of framework, but an architectural idea, there is a lack of sufficient constraints at the code level, resulting in a high threshold for DDD in practical application and easy to produce deviations in understanding.

Some people jokingly call DDD “High snow”.

  • Frames are easy to learn, ideas hard to learn
  • There are too few DDD best practices and no standards
    • In the practice of landing process, will find a lot of blank need to find their own solution, but do not know whether it is reasonable
  • Many concepts and terms emerge in DDD
  • DDD requires us to spend a lot of time and effort on domain modeling

DDD with Chinese characteristics

In the mid-stage scenario, DDD alone is not enough, and architecture supplement is needed for the characteristics of mid-stage.

In addition to the business model and layered architecture addressed by DDD, the following needs to be addressed:

  • Extension mechanism
    • Business logic extension
    • Business model extension
    • Business process extension
  • Business polymorphism
  • Front and center service decoupling, isolation mechanism
  • Ability to rise and sink mechanism

Why framework matters?

If every developer is allowed to implement their own architecture, you can easily end up with lots of optimised but fragmented ideas in the code base. Over time this becomes unmaintainable. It is better to have guidance and direction on how the software should be built into a single defined vision.

There should be one– and preferably only one –obvious way to do it.

State of the business development framework

There are many technical frameworks on the market, as well as some Low Code and even Codeless frameworks for simple business scenarios, but open source business development frameworks for solving complex business scenarios are currently blank.

The middle stage architecture, more stay in the idea and methodology, specific in the code level how to land, is blank at present.

DDDplus, a lightweight business mid-platform development framework, fills these gaps.

DDDplus

  • Based on DDD architecture, it is designed for complex business scenarios
    • The code framework provides enough constraints to make DDD more than just an idea
    • Reduce the threshold of DDD to reduce the burden of r&d and prevent landing deviation
    • Reduce complexity and continuously ensure that business assets can be deposited and inherited
    • Provide DDDplus-Archetype, which automatically generates engineering scaffolding including best practices
  • The 14 core business abstractions (9 commonly used) outline the skeleton of the business medium
    • The top-level design of the mid-platform architecture
    • Meet all changes with constancy
    • R&d fill-in-the-blank development
  • Solve business uncertainty in all directions
    • Extensions of business logic, processes, logical models, data models, polymorphic systems
    • The framework itself supports further extension
    • The extended service pack supports hot update without restart
  • Complex ecological coordination underpinning the China-Taiwan strategy
    • The front and middle stage are decoupled
    • Business isolation
    • InnerSource synergy mechanism
  • Complete solution
    • Business capability evolution, business testing, best practices, architecture continuity preservation, refactoring diversion validation, strangler landing solutions, etc
    • Provide a complete set of Demo projects, hand – in – hand real scene teaching