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.
Related
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.
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
Am Afraid If am Overdoing things here.
We recently started a .Net project containig different Class Libraries for DAl,Services and DTO.
Question is about our DAL layer we wanted a clean and easily maintained Data access layer, We wanted go with Entity Framework 4.1.
So still not clear about what to opt for Plain ADO.Net using DAO and DAOImpl methodolgy or
Entity Framework.
Could any one please suggest the best approach.
It depends on how much work you want to put into creating your own customized DAL. It is always better to use ADO.NET and your own implementations, but this also includes maintaining and optimizing it and treating complex cases such as concurrency, caching and the mapping of you BO, the DAL and the Database.
If you want to concentrate more on business value and functionality you might decide to go with Entity Framework (now 4.3 released and 5.0 to come). The advantage would be that you use a DAL that was carefully tested and that already contains solutions for concurrency, caching and mapping.
But I would hardly suggest using the Repository and Unit Of Work patterns on top of it to abstract the usage of Entity Framework out of your other layers. Then you would have the possibility to later completely change the underlying technologies without any impact on the other layers (you could replace EF with your own ADO.NET implementation if you see that the performance is not as good as it should be for example).
It depends on the type of application that you need to build and on its performance requirements. Using EF could really reduce your work and give you much quicker results. It also depends on the development teams capabilities. If you only have senior developers and architects working on the project then you will create you own DAL easily. But for beginners it is really hard to implement a good, optimized and robust DAL.
I hope that helps !
I've been using ADO.NET and DTO combination in DAL ever since i remember and i love the fact that i control the entire process of creating entities and methods. However that comes with the price of having to write classes for every entity and methods for every stored procedure. Which i don't mind, but recently i have discovered PLINQO for LINQ to SQL and I'm loving it. It gives you ease of creation/updating of Classes based on your Database schema while allowing for high levels of customization. Its basically LINQ2SQL on steroids.
I also liked nHibernate but i think it had steeper learning curve than PLINQO.
I'd give PLINQO a try if i was you
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
what is the best way is to use a ORM like Nhibertate or Entity Framework or to do a customer ORM .
I will use this ORM for a C# 4.0 project
UPDATE 2016
Six years later things are VERY different. NHibernate is all but abandoned, other alternatives were abandoned (eg Subsonic), Entity Framework is perhaps the most common full-featured ORM, and people have been moving to micro ORMs like Dapper for years, to map from queries to objects with a minimum of overhead.
The application scenarios have also changed. Instead of loading and caching one big object graph at the expense of memory and performance, Web Services and REST APIs need to service a high number of smaller requests. This means that a full ORM's overhead is no longer acceptable.
This means that patterns and techniques like Active Record, transaction per request etc have become throughput and scalability killing anti-patterns
One of the most important features nowadays is asynchronous execution , to reduce thread and CPU waste due to waits. NHibernate never made this transition.
Original Answer
Define "best": Is it the most mature, the one with more documentation, bigger community, more mainstream?
NHibernate is more mature, feature rich, with a more advanced community and not likely to be discontinued when MS decides to break compatibility again. Entity Framework is more mainstream and is supported out-of-the-box. You will find more beginner books for EF, more advanced books for NH.
A good option would be to try one of the simpler ORMs like Subsonic and move to more advanced ORMs once you understand how ORMs work, what are the various pitfalls, what SELECT N+1 means [:P]
Just don't try to create your own ORM, there are several dozens out there already! Subsonic, Castle ActiveRecord, NH, EF (of course), LLBLGenPro...
If you can spend some money, have definetely a look at LLBLGEn Pro 3.0
full .NET 4.0 support and it's a mature product. Good support it's also useful.
wide database support (Oracle,MS Sql,Firebird,MySql,PostgreSQL,Sysbase)
nice designer, Model first support and also Database first support
If your budget is thin, then try NHibernate. It's also a mature product,but It has a bigger learning curve. And if you need some support,you can always call Ayende :-)
For smaller projects it's EF 4.0 a good choice.
Most ORMs have their own strengths and weaknesses.
Entity Framework, for example, has the (huge?) advantage of being in the framework itself, but it also is fairly heavy-weight, and a bit more difficult to get up and running (steeper learning curve).
There are some very nice, very easy to use commercial ORMs. I'm currently using Lightspeed in a C# 4 project, and extremely happy with it for this specific scenario.
It really comes down to what you need from the ORM. If you want very quick and easy to setup and use, Lightspeed, subsonic, and others are very nice. If you need full featured, then Entity Framework and NHibernate are good options.
Calling an ORM the best amongst all in General perspective is completely impossible. Each of them are best from different perspectives. You chose the one that best fits to your needs. Linq2Sql was written with performance in mind but it lacks support for other providers,Linq2Sql is very fast. Yet there are others that may not be as fast as Linq2Sql when it comes to dealing with SQL server but they support wide variety of providers. The best idea would be to list down the features you want an ORM to have for your project and select the one that is serves all your needs.` You may ask these questions to chose the right ORM for your project.
What database providers you want the ORM to support ? SQL Server,MySQL, Oracle, etc.
Do you need model-first or db-first support ?
What is my performance criteria [memory, processing] ?
Are you going to use it in web-app or a desktop-app ?
Do you have distributed clients in your application ?
And the list goes on..
I use Linq-to-SQL as my main ORM when creating C# applications. I'll eventually move on to Entity Framework, but for now this one is really easy to use and fast.
I would agree with #this. __curious_geek that choosing the right ORM would depend on your requirements.Having worked on both Hibernate and Entity Framework, I feel the latter is more user friendly as it is a GUI based editor. On the feature richness front, NHibernate has an advantage of supporting a lot of database providers. Also customizing NHibernate turned out to be much easier than tweaking the Entity Framework.
Assuming the most tools satisfy your core requirement, I would prefer NHibernate as a vibrant and engaging user community is a big plus for any tool.
I just started getting into BizTalk at work and would love to keep using everything I've learned about DDD, TDD, etc. Is this even possible or am I always going to have to use the Visio like editors when creating things like pipelines and orchestrations?
You can certainly apply a lot of the concepts of TDD and DDD to BizTalk development.
You can design and develop around the concept of domain objects (although in BizTalk and integration development I often find interface objects or contract first design to be a more useful way of thinking - what messages get passed around at my interfaces). And you can also follow the 'Build the simplest possible thing that will work' and 'only build things that make tests pass' philosophies of TDD.
However, your question sounds like you are asking more about the code-centric sides of these design and development approaches.
Am I right that you would like to be able to follow the test driven development approach of first writing a unti test that exercises a requirement and fails, then writing a method that fulfils the requirement and causes the test to pass - all within a traditional programing language like C#?
For that, unfortunately, the answer is no. The majority of BizTalk artifacts (pipelines, maps, orchestrations...) can only really be built using the Visual Studio BizTalk plugins. There are ways of viewing the underlying c# code, but one would never want to try and directly develop this code.
There are two tools BizUnit and BizUnit Extensions that give some ability to control the execution of BizTalk applications and test them but this really only gets you to the point of performing more controled and more test driven integration tests.
The shapes that you drag onto the Orchestration design surface will largely just do their thing as one opaque unit of execution. And Orchestrations, pipelines, maps etc... all these things are largely intended to be executed (and tested) within an entire BizTalk solution.
Good design practices (taking pointers from approaches like TDD) will lead to breaking BizTalk solutions into smaller, more modular and testable chunks, and are there are ways of testing things like pipelines in isolation.
But the detailed specifics of TDD and DDD in code sadly don't translate.
For some related discussion that may be useful see this question:
Mocking WebService consumed by a Biztalk Request-Response port
If you often make use of pipelines and custom pipeline components in BizTalk, you might find my own PipelineTesting library useful. It allows you to use NUnit (or whatever other testing framework you prefer) to create automated tests for complete pipelines, specific pipeline components or even schemas (such as flat file schemas).
It's pretty useful if you use this kind of functionality, if I may say so myself (I make heavy use of it on my own projects).
You can find an introduction to the library here, and the full code on github. There's also some more detailed documentation on its wiki.
I agree with the comments by CKarras. Many people have cited that as their reason for not liking the BizUnit framework. But take a look at BizUnit 3.0. It has an object model that allows you to write the entire test step in C#/VB instead of XML. BizUnitExtensions is being upgraded to the new object model as well.
The advantages of the XML based system is that it is easier to generate test steps and there is no need to recompile when you update the steps. In my own Extensions library, I found the XmlPokeStep (inspired by NAnt) to be very useful. My team could update test step xml on the fly. For example, lets say we had to call a webservice that created a customer record and then checked a database for that same record. Now if the webservice returned the ID (dynamically generated), we could update the test step for the next step on the fly (not in the same xml file of course) and then use that to check the database.
From a coding perspective, the intellisense should be addressed now in BizUnit 3.0. The lack of an XSD did make things difficult in the past. I'm hoping to get an XSD out that will aid in the intellisense. There were some snippets as well for an old version of BizUnit but those havent been updated, maybe if theres time I'll give that a go.
But coming back to the TDD issue, if you take some of the intent behind TDD - the specification or behavior driven element, then you can apply it to some extent to Biztalk development as well because BizTalk is based heavily on contract driven development. So you can specify your interfaces first and create stub orchestrations etc to handle them and then build out the core. You could write the BizUnit tests at that time. I wish there were some tools that could automate this process but right now there arent.
Using frameworks such as the ESB guidance can also help give you a base platform to work off so you can implement the major use cases through your system iteratively.
Just a few thoughts. Hope this helps. I think its worth blogging about more extensively.
This is a good topic to discuss.Do ping me if you have any questions or we can always discuss more over here.
Rgds
Benjy
You could use BizUnit to create and reuse generic test cases both in code and excel(for functional scenarios)
http://www.codeplex.com/bizunit
BizTalk Server 2009 is expected to have more IDE integrated testability.
Cheers
Hemil.
BizUnit is really a pain to use because all the tests are written in XML instead of a programming language.
In our projects, we have "ported" parts of BizUnit to a plain old C# test framework. This allows us to use BizUnit's library of steps directly in C# NUnit/MSTest code. This makes tests that are easier to write (using VS Intellisense), more flexible, and most important, easier to debug in case of a test failure. The main drawback of this approach is that we have forked from the main BizUnit source.
Another interesting option I would consider for future projects is BooUnit, which is a Boo wrapper on top of BizUnit. It has advantages similar to our BizUnit "port", but also has the advantage of still using BizUnit instead of forking from it.