Why Jdon?


Differnce with Spring framework, Jdon framework is a event-driven framework, you need a asynchronous programming paradigm, because Implement event-driven scenarios using the traditional paradigm  is a thinking mismatch.

Traditional system request/response mode run through multi-layers, such as SOA or JavaEE, Business logic maybe exist in many places, so not easy to modify or extend it.

In a typical traditional system , the user request in the UI (in the browser, REST client or elsewhere) to the request parsing and dispatching in the web layer, to the service components in the middleware, through the caching and down to the database. If one of these layers does not participate—making blocking calls to the database, relying on shared mutable state, calling out to expensive synchronous operations—then the whole pipeline stalls and users will suffer through increased latency and reduced scalability.

In  event-driven scenarios , the user send a command from UI to Aggregate Root entity,this command will change the entity's state, so here we can introudce singel write pricinple, but in traditional request/reponse mode, when multi-thread access a resource, we usually use locks,sucah as database ACID or JTA(Spring or EJB session bean) or Optimistic lock(Hibernate/JPA), these locks are blocking synchronization.



Reactive EDA

  Jdon introduces reactive and event-driven into domain, a command activates a Aggregate Root's method by disruptor's single thread, and it will react a event again, here the command and the event are all nonblocking and asynchronous, the event can drive Respository saving data to database in another concurrent thread; in traditional scenarios one request use a thread from Controller of MVC to Service to Dao(saving data to database).,if in the long process there is a "synchronized" or a lock(even Optimistic lock), all other operations in this thread will be blocked, this is traditional performance bottleneck. Jdon moves mutable state from database to memory, and uses Aggregate Root to guard it, traditional database's data operations (by SQL or JPA/ORM) no need any more, only need send a Command or Event to drive Aggregate Root to change its mutable state by its behaviours. if you worry about im-memory state will lost when power off, you can in the meantime send a domain event(another thread) to persiste the state or this event that  lead up to that state, the domain event not blocks your state modification. you can have high throughput and lower latency.

  An Aggregate is not just an composition of objects that belong together to represent a certain state. An Aggregate manages behaviours that belong together, and keeps state only where they are relevant to those behaviours. jdon provides Command or Event to react those behaviours, instead of synchronous method calls.

  Traditional request response is a synchronous method calls. in Jdon event-driven scenarios ,The sender(producer) and recipient(consumer) can be implemented without regards to the details of how the events are propagated, allowing the interfaces to focus on the content of the communication. This leads to an implementation which is easier to extend, evolve and maintain, giving you more flexibility and reducing maintenance cost.

  A jdon application is non-blocking, under heavy load the app can have lower latency and higher throughput than a traditional application based on blocking synchronization and communication primitives. This results in lower operational costs, increased utilization and happier end-users.

  Domain events provided by Jdon can be used for Event Sourcing, We forget about persisting state altogether, and instead, we only persist the Domain Events that lead up to that state. We preserve the meaning, instead of the outcome. When we need the state, to make a decision, we replay the events and interpret them. The beauty of this, is that if we change our minds about how to interpret the behaviour, we are not stuck with the state the we decided to persist in the past.


In-memory object programming

  Jdon change Traditional programming, such as Spring + Hibernate/JPA, domain model is managed by Hibernate or JPA, and Spring manages services or components, in Jdon, domain model is not bind to any ORM framework, it is free POJO, and all services or components all run arround with domain model, model is not only any data collection or Anemia model.

  In Jdon, Traditional database ACID will be replaced by Singel write pricinple and eventSourcing, in-memory model no need any java multithread "synchronized" keyword too. no need any JTA provided by JavaEE, no need any lock.

  Jdon in-memory model can scale to cluster by datagrid such as Hazelcast, can build elegantly simple mission-critical, transactional, and terascale in-memory applications.