Richard Pawson of Naked Objects offers brief history of the framework and introduction to Naked Objects for .NET. Naked objects can be seen as Domain Driven Design taken to the extreme. With proper annotation, this framework can automatically generate a matching presentation layer in Java or .NET.
As the complexity of the real-life problems grows, it becomes obvious that in order to solve them, it is often necessary to combine multiple techniques. One example of a good symbiotic relationship is that between Service Oriented Architecture (SOA) and Domain Driven Design (DDD).
In this presentation filmed during QCon London 2007, Martin Fowler and Dan North talk about the communication gap existing between the developers and the customers or users. Closing this gap is extremely important in order to create successful software.
Domain driven design can be most readily applied to stable domains but it becomes more challenging when the domain itself is in a state of flux and development. This is common in Agile projects, and happens also when the business itself is trying to evolve. This article examines how we used DDD in the context of a two-year programme of work to rethink and rebuild guardian.co.uk.
In the second part of their article, Vasile and Michael explore the architecture of Dynamic Business Application as a possible standard architecture for server-side applications. The authors note that in this architecture concepts like SOA play a minor role while components like BPM engines, schedulers, messaging have a definite role.
A petition has started by the community to express concerns over Microsoft's upcoming release of the ADO.NET Entity Framework. The petition titled "ADO.NET Entity Framework Vote of No Confidence", aims to raise awareness of design and implementation issues foreseen by experts in the industry.
Domain-Driven Design is a subject where there currently are very few examples of how to actually do it in practice. In this article, Srini Penchikala gives you guidelines, practices, frameworks and tools that technical leads and architects can use in the effort of implementing a system in a Domain-Driven way.
Object Lifecycles (a.k.a State Machines) have been for the most part ignored by developers, architects and business process practitioners alike. A group of researchers from IBM Zurich has just released an Object Lifecycle modeling tool that complements and link with executable Business Process models.
The ADO.NET Entity Framework relies heavily on visual modeling tools. But are these tools really appropriate for large scale development?
In his last blog post, Johan den Haan asks one of the key questions of model driven engineering. The article is didactic and explains how ontological and linguistic metamodels can be combined (orthogonally) to simplify code generation while enabling the combination of general purpose languages and domain specific languages concepts. He uses BPEL and BPMN as a supporting example.
Peter Ritchie raised concern about TDD and BDD keeping practitioners from writing good unit tests. He cites an over-reliance on “interaction testing", a core mantra and essence of TDD and BDD, as a driver with tendency to result in incomplete unit testing.
Today, many projects focus on Domain-Driven Design, but it is not always easy. One of the most important things are to separate the domain code from the code that only exists for technical reasons. Mats Helander has written an article where he explains how to manage domain models and teaches design patterns and aspect-oriented programming in the process.
Charles Simonyi, the President of Intentional Software and a recent space traveller presents his views on the future of software development. He talks about how to include domain experts in the development cycle by letting them express their intentions in domain specific languages, about Intentional's view on DSLs and Domain Driven Design and about what it was like to be a space tourist.
In this talk, Eric Evans introduces two broad principles for strategic design. 'Context mapping' addresses the fact that different groups model differently and 'Core domain' distills a shared vision of the system's core domain and provides a systematic guide to when good enough is good enough versus when to push for excellence.
Naked Objects is an architectural pattern and a framework for developing applications where domain objects takes a central role. Naked Objects recently released version 3.0 with support for Java 1.5, injection, an alternate UI, Hibernate object store, integrated security and contributed actions. InfoQ took the opportunity to speak with Richard Pawson, inventor of the Naked Objects pattern.