By gathering all domain experts and developers in a room, provide them with a paper roll, lots of colored post-its and a facilitator they may in hours create the best model ever, Alberto Brandolini suggested at the recent DDD Exchange conference in London.
Delay of message sending into the future is a very powerful pattern and is often the preferable way of dealing with temporal problems compared to batch job that will run a query on the domain model and update some aggregates, Greg Young explained at the recent DDD Exchange conference in London.
High performance systems is about clean and representative models, the code doesn't have to be ugly, obscure and hard to read, Martin Thompson stated at the recent DDD Exchange conference in London.
We need to constantly challenge DDD to find the weak spots, Eric Evans stated in his keynote at DDD Exchange yesterday in London when walking through and challenging his own fundamental assumptions of Domain-Driven Design.
The sixth DDD Exchange Day in London is due in three weeks with a speaker list including Eric Evans, Martin Thompson, Alberto Brandolini and Greg Young. Eric will in his opening keynote challenge the fundamental assumptions of DDD and dig into the root assumptions to challenge each of them.
Implementing Domain-Driven Design (DDD) concepts using object orientation principles with state and behaviour often gives you a muddled mutable model, instead building domain objects with only state and behaviour as standalone functions leads to a better realization, Debasish Ghosh claims in a recent blog post.
A focus on behaviour and a more declarative style of code are two benefits for Domain-Driven Design (DDD) when moving from an object-oriented language like C# to a functional one like F#, Lev Gorodinski claims in a recent presentation, using an example that includes event sourcing and Command-Query Responsibility Separation (CQRS) to show some of the benefits and challenges in a move to F#.
Using a functional language in domain-driven design (DDD) the actual code can often become simple enough to be used instead of UML diagrams when discussing with domain experts, Scott Wlaschin stated in a recent talk about domain modelling together with functional programming using F#.
Domain-Driven Design, DDD, is all about the domain, not about persistence. With a history of database programming for 25 years, later years using Entity Framework, Julie Lerman, a consultant on the .NET platform and a Microsoft MVP, in a recent presentation at the Øredev developer conference shares her persistence experiences when moving into DDD.
The domain describes your business and in Domain Driven Design, (DDD), the domain is the most important ingredient of the application, Andras Nemes explains when starting a series of blog posts on building a web service based on Domain-Driven Design principles. His goal is not to cover all details and aspects of DDD, his ambition though is that also developers completely new to DDD can benefit.
With a long history of data-driven development, Julie Lerman shares her experiences moving into using her skills with Domain-Driven Design in three articles, with examples in C# using Entity Framework
Start using Behaviour-Driven Development (BDD) when designing an application and focus on the domain instead of the database, Julie Lerman, a Microsoft MVP since 2003, suggests. BDD lets developers focus on user stories and behaviour in the business domain when building up logic and tests. New to BDD, Julie has implemented a working example using Visual Studio, C# and SpecFlow.
Architecture is about intent, we have made it about frameworks and details, Robert C. Martin, “Uncle Bob”, stated earlier at this year’s DDD Exchange Day in London. Robert refers to a book by Ivar Jacobson from 1992 and brings the original thoughts about use cases into architecture models, e.g. Hexagonal architecture and Clean architecture to improve these models.
To take advantage of the great concurrency opportunities the new multi-core machines gives us we should use a programming model that helps us achieve this, and the Actor model gives us a number of tools for doing that, Vaughn Vernon stated at this year’s DDD Exchange Day in London.
The first thing a team should do on a new software project is drawing a context map to help them understand the context, the core domain and what other contexts they may need to interact with to get a shared understanding of the domain between everyone involved, Paul Rayner explains when sharing his experiences what kind of documentation teams doing Domain-Driven Design, DDD, should produce.