Synopse Open Source

The somewhat "official" definition of Domain-driven design is supplied at http://domaindrivendesign.org:

Over the last decade or two, a philosophy has developed as an undercurrent in the object community. The premise of domain-driven design is two-fold:
- For most software projects, the primary focus should be on the domain and domain logic;
- Complex domain designs should be based on a model.

Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

It can be implemented in a kind of Multi-Tier architecture.
In this case, we are talking about N-Layered Domain-Oriented Architecture.
It involves a common representation splitting the Logic Tier into two layers, i.e. Application layer and Domain Model layer.

Of course, this particular layered architecture is customizable according to the needs of each project.
We simply propose following an architecture that serves as a baseline to be modified or adapted by architects according to their needs and requirements.

It could therefore be presented as in the following model:

In fact, this design matches perfectly the RESTful SOA approach of the Synopse mORMot framework.

See the following diagram:

In fact, since a good SOA architecture tends to ensure that services comprise unassociated, loosely coupled units of functionality that have no calls to each other embedded in them, we may define two levels of services, implemented by two interface factories, using their own hosting and communication:
- One set of services at Application layer, to define the uncoupled contracts available from Client applications;
- One set of services at Domain Model layer, which will allow all involved domains to communicate with each other, without exposing it to the remote clients.

Therefore, those layers could be also implemented as such:

Due to the SOLID design of mORMot - see this article - you can use as many Client-Server services layers as needed in the same architecture (i.e. a Server can be a Client of the same process or any other processes, locally or remotely), in order to fit your project needs, and let it evolve from the simpliest architecture (e.g. a stand-alone executable with SQLite3 included) to a full scalable Domain-Driven design working with a Oracle database. 

In order to provide the better scaling of the server side, cache can be easily implemented at every level, and hosting can be tuned in order to provide the best response time possible: one central server, several dedicated servers for application, domain and persistence layers...

With mORMot, your software solution will never be stucked in a dead-end.
You'll be able to always adapt to your customers need, and maximize your ROI.

The main presentation page of our framework has been updated, and provide a clear view of this N-Layered architecture.

Feedback is welcome on our forum.
More to come, including updated documentation!