Chapter 1. Removing duplicate code

Chapter 2. Turning comments into code

Chapter 3. Removing code smells

Chapter 4. Keeping code fit

Chapter 5. Take care to inherit

Chapter 6. Handling inappropriate references

Chapter 7. Separate database, user interface and domain logic

Chapter 8. Managing software projects with user stories

Chapter 9. OO design with CRC cards

Chapter 10. Acceptance test
Chapter 11. How to acceptance test a user in
Chapter 12. Unit testterface

Major changes in technology have not been driven by the technologies themselves but by the change in thinking that they enabled.  OO design changed software by changing thoughts away from procedures and onto real world "things".  This book argues that for SOA to succeed we must move our thoughts away from the implementation technologies and towards the "what" of the business.  Using a straight-forward, pictorially driven, methodology the book explains who to discover what the business services really are and how to construct an overall business service architecture

Table of contents
This book is a short, quickly-readable summary and introduction to the fundamentals of DDD; it does not introduce any new concepts; it attempts to concisely summarize the essence of what DDD is, drawing mostly Eric Evans' book, as well other sources since published such as Jimmy Nilsson's Applying Domain Driven Design, and various DDD discussion forums.  Chapters of the book include:

1. Building Domain Knowledge
2. The Ubiquitous Language
3. Model Driven Design
4. Refactoring Toward Deeper Insight

Product

Xanalys's Common Lisp Object Request Broker ? (ORB ? ) supports the Common Object Request Broker Architecture (CORBA ® ) defined by Object Management Group ® , Inc. (OMG ? ).

The LispWorks ORB and supporting tools provide CORBA architecture functionality to Common Lisp programmers, combining standardized distributed system development with a state-of-the-art dynamic object-oriented language.
Parts

The CORBA components included in The LispWorks ORB are:

Traditional methodologies also try to be predictive - to create a schedule at the beginning of a project and to conform to this schedule for the life of the project. Yet a common complaint is “the problem with this project is that the users keep changing their minds”. In the physical world people accept that requirements need to be fixed because it's intuitively obvious to them that, because of the expensive construction phase, it's very expensive to make changes after a certain point. However, software is much less tangible.