Is there a cross language framework like axon framework?
I need a cross language DDD framework supporting Java, .Net, nodejs, golang
There are multiple development languages in my company,I expect to implement DDD without changing the programming language used by developers
I expect a cross language development framework
The greater part of the value of DDD comes from the strategic patterns, which are non-technical. Take a look at this video for an overview: Strategic Domain-Driven Design by Nick Tune
Then on the technical side, your domain code can remain pretty framework free and using hexagonal/ports and adapters/clean architecture whatever framework is most mature/productive can be used for the implementation of repositories/services/APIs/busses etc.
That being said, DAPR is the 1st cross-language framework I have seen (that is less intrusive than Service Fabric) that ticks a lot of the boxes. I will say it is still early in development and I have not used it in any meaningful way myself.
One approach to satisfying this requirement is to use a service oriented/microservices architecture.
Essentially, you would be exposing all of your domain behavior via a set of interfaces that are implemented via REST-ish apis. What that means is that the implementer of a service can create their service in any language independent of what the clients of the service are using.
Something like Akka Serverless from Lightbend would fit the bill: business logic can be implemented in any language which supports gRPC.
Related
I am attending a training course where they presented the following graphic as the Anatomy of a Typical Java Web Application. Is it too sweeping of a statement, or is it largely accurate?
Here it goes:
(Disclaimer: My experience is drawn mostly from non-Java platforms, though I have some limited experience with Java - but mostly I'm not a fan)
It's accurate - but only for applications using that architecture - which makes this statement somewhat of a tautology.
I'll break it down:
Service Consumer Perspective
A "service consumer" is also more commonly known as a client.
"Service interface files" are not needed to build a client.
I assume by "interface files" it's referring to things like a SOAP WSDL document or Swagger file for REST services. These files are not generally used by clients at runtime but are used to automatically create client class-libraries at design-time - but you can always build a client without any code-generation or reuse of Java interface types.
If it is referring to the reuse of the server/application's Java interface types then the diagram is only accurate for client+server applications that are all-Java and are both designed/created at the same time (which is an old practice from the days of SOAP). Thesedays everything made in the past 5-10 years is RESTful and returns JSON data, but Java interface types are insufficient to model unstructured data like JSON (given you can't model discriminated-unions without concrete classes... in exception handlers, egods, and discriminated-unions are an important tool to model JSON in OOP languages).
Service Provider Perspective
I disagree with the use of the term "Front controller" being used to refer to what is commonly known as a back-end web-service controller, Servlet, or Spring Controller as "front-end" generally refers to the user-facing UI/UX, such as the rendered HTML+JS, an SPA front-end, or rich-client/fat-client (granted, this would be the "service consumer").
You don't need "service metadata" to have a web-application or a web-service - though if you're shipping a web-service designed to be consumed by disparate or non-first-party clients then its a good idea to make a WSDL, Swagger, or whatever metadata or service-description system your platform uses so that your consumers can generate their own strongly-typed clients.
"Service implementer perspective"
So this is my biggest objection: this diagram assumes that the web-service will be 3-tier and the controller/Servlet code is only a thin layer in front of "application" types located elsewhere in the system. While this is common in large-scale and complicated applications where you'll have host-agnostic application code that is designed to be able to run in, for example, an integration-test or unit-test host - or as a desktop application, in my experience I estimate most projects lump all application logic inside the host-specific (i.e. Spring, Servlets, etc) code because it simplifies things greatly (and because those hosts often support testability anyway - and the idea of reusing application code libraries as-is for desktop or mobile applications just doesn't work out well in reality given the massive differences between the disconnected and stateless model of web-service requests compared to the needs of stateful in-process client applications).
In summary: it's not wrong, but I don't believe it accurately describes the majority of (Java) web-applications I've personally dealt with... but this is my subjective opinion and I know that Java web-application and web-service frameworks like Spring and Java EE are designed for and encourage 3-tier architecture, I wouldn't describe them doing-so as an example of the pit-of-success - I feel this is partly due to shortcomings in the Java language design (and the fact these frameworks were designed over 20 years ago before things like generics were added to the language).
I am in the process of moving an application from c# to node.js. I am learning node.js as I go along, so I am a node.js newbie. I am reading the book, Patterns, Principles and Practices of Domain Driven Design and found a lot of great information my current project could benefit from.
For instance, in the book, there is a sample e-commerce application that contains three bounded contexts: sales, shipping and billing. Each bounded context is responsible for its own database and each bounded context is running in an instance of NServiceBus. This seems to be a great approach as everything is running under the same solution, but different projects. In translating this to node.js, I am having a few areas of confusion.
1) I am having a rough time finding good examples that incorporate node.js with ddd like the e-commerce example above? Some of the hurdle here is the difference in how OOP is handled.
2) If in the book sample code, each bounded context is in its own project and runs within NServiceBus, would this mean that in translating this to node.js, I am using vscode as GUI, that I would need to create a separate parent folder(bounded context) for each project and supply a different port for each bounded context to listen on if I want all of the bounded contexts to run on the same server until I need to scale accordingly?
3) NServiceBus allows messages and events to get passed back ad forth. For node.js, what service bus technology, preferably open source and can run on linux-based machine, exists that would provide the kind of functionality NServiceBus provides and reliably? Should I just look at using rabbitmq alone to provide this functionality including sending events?
You might be interested in wolkenkit, a CQRS and event-sourcing framework for Node.js and JavaScript that plays very well together with domain-driven design (DDD).
Besides the actual framework (which is deployed as npm module wolkenkit), there are a number of sample applications available that show how things work:
wolkenkit-todomvc is the classical TodoMVC application modeled using DDD
wolkenkit-boards is a team collaboration software similar to Trello
wolkenkit-nevercompletedgame is the wolkenkit version of the game at nevercompletedgame.com
wolkenkit-geocaching is an application to manage caches for geocaching
Apart from that you might want to take a look at the wolkenkit documentation, and there again especially at the brochure you can download which explains DDD, event-sourcing and CQRS, what they are, how they relate to each other, and so on…
PS: Please note that I am one of the authors of wolkenkit, so please take my answer with a grain of salt.
I would suggest going through the npm modules tagged with ddd:
https://www.npmjs.com/browse/keyword/ddd
and tagged with service bus:
https://www.npmjs.com/browse/keyword/servicebus
There is also a JavaScript Domain-Driven Design book by Philipp Fehre.
This post is a couple of years old, but for anyone still interested there's a DDD framework for Typescript/node at:
https://github.com/node-ts/ddd
As well as an NServiceBus inspired message bus at:
https://node-ts.github.io/bus/
They're designed to work together to build message driven DDD systems with node
We're starting a web application using DDD and CQRS (using the ncqrs framework) and before we get started writing our own infrastructure class library, i wanted to see if any are already available.
I'd think at least some basic interfaces and common implementations for writing to the file system, sending emails, etc could be used in any project.
Those types of services are sufficiently context dependent to be unyielding to common frameworks above the facilities provided by the .NET Framework. There may frameworks centered around specific tasks, such as emailing, however you're better of selecting a solution that fits the requirements, instead of the converse. Instead, consider reviewing some sample DDD projects as listed here.
I agree with what eulerfx stated earlier. I'd add that if you depend upon a framework for using DDD and CQRS, then you risk depending on the framework and not truly understanding what is happening. As a result, you may miss what DDD (and CQRS) is providing to you.
I will state that I started off learning about CQRS by using a framework (NCQRS in fact), but my DDD knowledge was based on Evans' book and I didn't look for a framework for modeling my domain. As each domain is unique to the problem, I think it's hard to truly have a framework that "helps" you implement DDD.
In retrospect, I wish I had not gone with NCQRS right from the start as I missed or passed over some of the subtleties of the CQRS pattern.
There are probably some DDD frameworks out there, but I'd recommend forgoing them and build your own. You'll thank yourself later.
Hope this helps. Good luck!
You can try my library CoreDdd, documentation here, blog posts about it here. It contains support for DDD (entities, aggregate roots) and CQRS (commands, queries). No support for writing file system or sending emails, use standard .net for this.
What is the difference between the next terms, it can help a lot in interviews and general understanding.
Framerwork
Library
IDE
API
Framework
Some predefined architecture that a developer has chosen and which dictates how the application will be written. It usually already includes many concepts which helps the developer to concentrate on the domain of the application instead of the plumbing. This plumbing is provided by the framework. For example the .NET framework provides out-of-the-box tools that would allow you to talk to web servers, without even knowing the internals of the TCP/IP protocol (actually it helps knowing the internals but you get the point).
Library
A reusable compiled unit that can be redistributed and reused across various projects. Well not necessary compiled in case of dynamic languages.
IDE
It's the development environment where you create the other three parts (usually text editor), it might also include compiler and the possibility to execute, debug and see the output of the program in order to speed up the development process.
API
Application Programming Interface. This could mean many things but usually it is a set of functions given to the disposition of the developer and which perform specific tasks and work only in a specific context.
IDE is a tool for fast, easy and flexible development
An API is provided for an existing software. Using these third party applications can interact with main/primary application.
A framework or library are typically same. They are a common set of functionality for other software to use.
Ref: wiki for Framework, API
Framework: a collection of libraries and programming practices to provide general functionality for a program, so that it doesn't have to be rewritten. Typically a framework for an application program will handle user display and input, among other things. The intent is usually to hide the more complex functionality of an application, and to encourage a certain style.
Library: A piece of software to provide certain functionality to other programs that call it. Typically designed to be reusable and modular, so that a library can be distributed and be useful without its source code.
Integrated Development Environment: A integrated set of tools to write programs and turn them into finished products, usually including at least an editor, compiler, linker, and debugger. IDEs sometimes provide support for frameworks.
Application Programming Interface: A set of function calls and sometimes variable accesses available to a program, typically being the public interface of one or more libraries.
I'm in the beginning phases of a Blackberry/J2ME project -- and along with other limitations that come with this wonderful platform, the lack of support for reflection and 1.3 language level mean that the vast majority of existing IoC containers are unusable. (Google has Guice for Android with no AOP, but even that requires support for annotations).
So the space of IoC containers on J2ME is pretty limited. The one framework that has caught my attention is called Signal Framework, and it looks pretty promising. It tries to stay conceptually close to Spring Framework's IoC, implementing a small subset of its functionality, and does so without relying on bytecode-modification or causing runtime xml parsing. Instead, it processes configuration XMLs at build-time to generate java code which implements this IoC functionality.
Generally speaking, code generation at build time seems like a very wise approach for mobile applications -- and if my app has to do less XML parsing on user's device, that's great too!
So, what have your experiences been with implementing IoC on J2ME/CLDC, and how were you able to extinguish that bitter taste in your mouth?
We used Spring ME at TomTom. It worked out pretty well.
In J2ME you need to reduce the number of classes you use as much as possible to reduce the size of jar files. This leads to many design compromises not least of which is flexibility.
It is not easy to adjust to J2ME development when you have to throw must of what you hae learnt (and come to value highly) about OO out the window. The truth is if you want apps that can run on a large range of phones you need to be very sensitive to the constraints of the devices.
As such I do not think an IoC framework will match many people's needs for J2ME development.
You might be interested in checking out FallME. Even though I haven't used it personally, it seems like a no non-sense framework built specifically for the J2ME platform.
I came across Spring ME during a Dutch JUG conference (have no experience with it whatsoever).
Signal Framework it is.
Update: unfortunately, Signal is very undercooked right now, so I'm going with Israfil IOC with custom additions.