Domain-Driven Design Quickly

Model ?

Model = an abstraction of the domain = internal representation of the target domain = essential part of software design

What Is Domain-Driven Design

• Software Specialists와 해당 도메인 영역의 전문가가 만나서 도메인을 구성할 모델을 만들어내는 Design 과정.(Building Domain Knowledge)
• Essential Concept을 먼저 찾고, 이어서 살을 덧붙여 모델을 만들어 나간다.

The Ubiquitous Language

• A core principle of domain-driven design is to use a language based on the model.
• Use the model as the backbone of a language.
• Make sure this language appears consistently in all the communication forms used by the team
  • for this reason, the language is called the Ubiquitous Language.

MODEL-DRIVEN DESIGN

Most important patterns to be used in model-driven design.

Four conceptual layers

User Interface   Responsible for presenting information to the user and
(Presentation    interpreting user commands.
Layer)
Application       This is a thin layer which coordinates the application
Layer               activity. It does not contain business logic. It does not
                       hold the state of the business objects, but it can hold
                       the state of an application task progress.
Domain Layer    This layer contains information about the domain. This
                       is the heart of the business software. The state of
                       business objects is held here. Persistence of the
                       business objects and possibly their state is delegated to
                       the infrastructure layer.
Infrastructure    This layer acts as a supporting library for all the other
Layer                layers. It provides communication between layers,
                       implements persistence for business objects, contains
                       supporting libraries for the user interface layer, etc.

Refactoring Toward Deeper Insight

• Make the implicit concepts explicit.
  • Placing the Constraint into a separate method has the advantage of making it explicit
  • Processes are usually expressed in code with procedures. 서비스나 Strategy로 절차를 구현한다.
  • Specification is used to test an object to see if it satisfies a certain criteria. Specification Object를 만들어 함수를 모아둔다.

Preserving Model Integrity

A unified enterprise model is an ideal which is not easily accomplished, and sometimes it is not even worth trying it.
서로 연관성 있는 모델들이 병행개발되어, Model Integrity를 맞추기란 쉽지 않다.

A set of techniques used to maintain model integrity.

DDD Matters Today

DDD 리소스

1. DDD 공식 사이트
2. Dan North – 사용자 스토리 작성 방법
3. 커다란 진흙덩이 아키텍처 스타일
4. Greg Young 블로그 – CodeBetter
5. 단일 책임 원칙에 대한 Robert C. Martin의 논문
6. Brad Appleton – 데메테르의 법칙에 대한 소개
7. Martin Fowler – 계층 슈퍼 형식 패턴에 대한 설명
8. Robert C. Martin – S.O.L.I.D. 원칙에 대한 설명
9. MSDN Magazine Best Practice – DDD(Domain Driven Design) 소개

참고 링크

• 2009/07/29 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 9부
• 2009/07/13 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 8부
• 2009/06/29 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 7부
• 2009/06/23 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 6부
• 2009/06/15 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 5부
• 2009/03/25 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 4부
• 2009/02/27 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 3부
• 2009/02/23 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 2부
• 2009/02/15 Domain-Driven Design의 적용-4.ORM과 투명한 영속성 1부
• 2009/01/18 Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 7부
• 2009/01/02 Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 6부
• 2008/12/24 Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 5부
• 2008/12/17 Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 4부
• 2008/12/13 Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 3부
• 2008/12/09 Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 2부
• 2008/12/05 Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 1부
• 2008/11/30 Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 5부
• 2008/11/27 Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 4부
• 2008/11/25 Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 3부
• 2008/11/23 Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 2부
• 2008/11/20 Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 1부
• 2008/11/17 Domain-Driven Design의 적용-1.VALUE OBJECT와 REFERENCE OBJECT 4부
• 2008/11/17 Domain-Driven Design의 적용-1.VALUE OBJECT와 REFERENCE OBJECT 3부
• 2008/11/16 Domain-Driven Design의 적용-1.VALUE OBJECT와 REFERENCE OBJECT 2부
• 2008/11/15 Domain-Driven Design의 적용-1.VALUE OBJECT와 REFERENCE OBJECT 1부

[출처] http://aeternum.egloos.com/tag/DomainDrivenDesign

Welcome

With Christmas just around the corner we’re celebrating the year with two geek dinners. The first in Edinburgh on the 4th December and the second in Glasgow on the 12th December. There are only a few places left as most went when we announced them on Twitter.

If you are on twitter you can follow us @scottishdevs.

If you were signed up to our Advanced TDD event which we had to cancel at the last minute then you may be interested to know that it has been rescheduled and will be on 8th December.

We announced our annual conference, Developer Day Scotland (part of the DDD community conferences), this month too. It will be on the 8th May 2010. The call for speakers is now open, so if you have any sessions (60 minutes) that you’d like to give then please register on the site and submit your session. In the new year we’ll be opening the sessions up to voting so you can have your say on what sessions you want to see. For those on twitter you can follow @dddscot to get the latest news about the conference.

If you run a user group, or just know of an event that would be of interest to software developers we’re always keen to hear about it. Let us know by sending an email to support@scottishdevelopers.com

Regards,
Colin Mackay, Chairman, Scottish Developers

Our Upcoming Events

4-December-2009 @ 19:30 in Edinburgh
Edinburgh Geek Dinner – Amber Restaurant
Registration Required

8-December-2009 @ 18:30 in Glasgow
Advanced TDD – An Introduction to Testing Patterns and Behaviour Driven Development
Registration Required – Cost FREE

12-December-2009 @ 21:30 in Glasgow (Meeting in the pub from 19:00, meal at 21:30)
Glasgow Geek Dinner – La Tasca
Registration Required – Cost: Price of meal

Introduction

Most enterprise applications use Layering as the primary technique to break the complexity of the software projects. Layering involves breaking down the applications in various layers where each layer lie above the other and provide services to the higher layer. Layering provides following benefits

• You can understand about a layer without knowing about other layers. For example, if you know how TCP works you can create your own FTP service without actually knowing about the internals of the ethernet.
• It is easy to substitute the layers with alternative implementation. For example, if DAO layer is designed properly, if should be easy to change the ORM solution from Hibernate to iBatis easily.
• Layering also helps in standardization and extensibility.

But the downsides of layering applications include cascading changes, performance overhead of converting data from one representation into another and it is not often easy to decide the later of a particular component. Considering the benefits of layering and it’s applicability to almost any sort of computer application, it is used widely and successfully.

Three primary layers of an enterprise application can broadly be categorized into

1. Presentation Layer: Information display, HTTP requests, command line invocations, batch API, etc.
2. Domain Layer: Here lies the “Heart of the software”
3. Datasource Layer: Provides access to external resources like databases, messaging, mail server, etc.

In this blog, we will discuss various patterns of organizing domain logic and specific pros and cons of each. We will also discuss how these approaches compare with each other.

Domain Login Patterns
In his book, PoEEA, Martin Fowler has classified domain logic patterns into three primary patterns: Transaction Script, Domain Model and Table Module. He also discussed introducing an additional layer, Service Layer, which is useful in providing horizontal services. Let’s look at each of these in detail.

Transaction Script (TS)
Transaction script is essentially a procedure that takes input from the presentation, processes it with validations and calculations, stores data in the database, send emails, etc. It may also fetch the data and send to the UI. It’s more like coding a C program in Java. Typically, in transaction script method of organizing domain logic, the code is segregated into various services and each service has methods that perform a particular business functionality. A method of a transaction service might look like this

void tsmethod(params) {
   // get data
   // process data
   if () {
   } else if {
   } else {
   }
   // insert/update/delete data
   //send email
}

As you can see from the above, most of the of the above code is procedural. Here, the services act on the entities. A typical example would be an interaction between session bean and entity bean. Another similar pattern not mentioned in the PoEEA is Anemic Domain Model (ADM) which works on the same principle where domain objects have attributes and relationships but does not have behaviour. Behaviour is provided by the services. The different between TS and ADM is that in former we do not have domain objects but rather have something which Fowler describe as Table Data Gateway, which essentially is a wrapper for SQL queries.

Domain Model (DM)
In domain model approach, both behaviour and data are encapsulated inside the domain objects. Domain model looks different from the database design and utilizes inheritance, strategies, and other design patterns to create complex webs of small interconnected objects. A typical domain model code might look like

class Bar {
  private BarAdmissionPolicy = new BarAdmissionPolicy();
  public void admit(Person person) {
     if (BarAdmissionPolicy.isAllowed(person)) {
         this.add(person)
     }
  }
}
public class BarAdmissionPolicy {
   public boolean isAllowed(Person person) {
     if (person.age > 18) {
        return true;
     }
     return false;
   }
}

A well designed domain model provides an abstraction of the domain logic. It encapsulates complex business logic as interactions between domain objects.

Table Module (TM)
It is essentially a singleton instance that handles the business logic for all the rows in a database table. There is no concept of identity in a Table Module. It is designed to operate on entire table data. A typical domain might look like

class Product {
 void insert(name, type, etc) {
 }
 void insertAll(List) {
 }
 void calculateProductCost(List productIds) {
 }
}

As you can see, a table module encapsulates the data and behaviour of the entire table. It is most commonly used in places where UI widgets are data-aware like Oracle Forms or .Net environment which has Visual Studio, which provides tools like RecordSet.

Service Layer (SL)
A Service Layer defines an application’s boundary and its set of available operations from the perspective of interfacing client layers. It encapsulates the application’s business logic, controlling transactions, applying security and coordinating responses in the implementation of its operations. Service Layer can be thick or thin depending upon whether you are using transaction scripts or domain model.

Now, we have understanding of the various domain logic patterns, let’s discuss how they compare with each other.

Comparison
Essentially, if you are using one of DM, TM or ADM pattern, the domain layer can be split into two layers: SL + DM/TM/ADM. SL is essential in providing horizontal services like security, transactions, etc. With TS in practice, it is difficult to identify the difference between SL and TS since TS can double up as a SL also.

Since, TM emphasizes one class per table, there are issues in implementing OO concepts while inheritance. There are no direct relationships between objects. For example, if you want to get a List of Products and Categories separately then it is easy to define where to put the code, but it is not clear where to put the code if you need a RecordSet which contains both Products and Categories.

TS is more like a service class which makes implementing domain logic difficult when the complexity of the application increases, but works well for simple applications.

There is a tough competition between ADM and DM. DM is essentially a Rich Domain Model (RDM). Common things between them includes data and relationships. But things specific to RDM is behaviour of the domain model. There has been a heated debate between designers to prove the dominance of one over the other. Suprisingly, the wiki page for ADM lists why should be avoid them. I reiterate them here

• Logic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.
• Violation of the principals information hiding and encapsulation.
• Necessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model’s objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
• Necessitates a global access to internals of shared business entities increasing coupling and fragility.
• Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.
• Necessitates a service layer when sharing domain logic across differing consumers of an object model.
• Makes a model less expressive and harder to understand.

The difference between ADM and RDM is the focus of control. In the former, the services has the control and in the later domain objects controls the services. It is shown in the following diagram.

Another benefit that differentiates ADM and RDM is that in ADM a developer has to understand two layers, service layer and domain layer but in RDM once you get the grasp of domain model, which is essentially a model of the domain logic, you get a grasp of the business and can work productively to enhance the software. RDM also makes code cohesive.

Experts also advocate to consider maintainability while deciding to choose between various approaches. In his book PoEEA, Fowler explains this with the help of a diagram which is shown below

The source of the above diagram is not known. But, according to this diagram, it takes time to pick up speed with the domain model. Of course, with skilled developers the initial startup time reduces. But, as the complexity of the application increases, it becomes increasingly difficult to maintain the application if it is coded with TS pattern. TM pattern delays the cutoff point where DM takes over, but TM is advocated for .Net environments as Visual Studio provides tools which work well with TM.

Conclusion
In this blog, we discussed various patterns for organizing domain logic in enterprise applications. Clearly, there is no silver bullet which fits all scenarios. Since, we work with object-oriented programming languages, it is advisable to work with approaches like DM to encapsulate business logic. Also, it makes working with complex applications easier as the complexity of the application increases. DM helps in abstracting a model of the real world domain logic in the code which once understood can make working on the applications more productive and fruitful. For simple applications, TS/ADM meets the requirements.

But, how to decide whether the application is complex or easy. Most of the metrics talk about the complexity once the software has been coded by analyzing if-else statements, cyclomatic complexity, etc. But, here, we are talking about predicting complexity, and there is no known metric which can objectively tell that. However, it can be subjectively predicted by knowledge of the domain of the software, which is gained by experience.

Another and most important factor which must be taken into consideration is maintainability. Although it cannot be quantitatively measured, but since we work in to the objective oriented world, DM seems to have an edge over other approaches and it employs inheritance, polymorphism, etc to encapsulate the domain logic.

As a final word, all the above domain model patterns are not mutually exclusive and an understanding of all of above might help us decide an approach for developing a particular software.

Ho visto colleghi preparati e curiosi, ho visto emergere spunti interessanti dalla sintesi di posizioni diverse, ho sentito spunti nuovi ed interessanti. Ho incontrato persone piacevoli che non conoscevo e che ora sono onorato di conoscere.

Tutto questo non succede tutti i giorni, ed in tutti i posti.

Un Grazie a Marco Abis, che ogni anno rende possibile questa magia. Un grazie all’organizzazione ed agli amici dell’XPUG Bologna che sono stati ancora una volta spettacolari. Un grazie ai colleghi speaker pronti a “mettersi a nudo” senza troppi fronzoli. Un grazie a chi ha partecipato al mio intervento stile “Ballarò” condividendo idee e spunti interessanti. Un grazie al manipolo di eroi che ha rischiato l’asfissia per seguire il mini-workshop pomeridiano su Domain Driven Design. Un grazie anche al Bettazzoni che mi ha ricordato cosa vuol dire essere Romagnolo.

È stata una bella giornata.

Grazie a tutti

Hoje, depois de uma proposta vinda na segunda-feira, a diretoria do Agora Vai Futebol Clube emprestou o camisa 31, DDD, ao recém fundado Terceiro Boladão FC, para participar de um campeonato local.

Terceiro Boladão FC

Como o time não vem nem ao menos treinando, a diretoria optou por fazer o empréstimo, até mesmo para manter a forma física do jogador. Perguntado a respeito, o técnico alemão disse que está orgulhoso de seu filhote e espera que ele consiga atingir uma boa performance nas partidas. E que tudo isso traga uma melhora significativa no desempenho do mesmo akee no AVFC.

DDD já tirou foto com a nova camisa, e disse que está ansioso para voltar a jogar bola, atividade a qual não realiza há um bom tempo. A camisa atribuída ao jogador é, segundo a imprensa, a melhor camisa já criada na história do futebol mundial. Como uma imagem vale mais que 1000 palavras, terminaremos o post com a foto e com a torcida dos agoravaianos pelo nosso camisa 31. “DDD, estamos contigo. Eh isso ae”.

DDD, com a camisa do Terceiro Boladão, número 99kg.

Foto ganadora del concurso

Anselmo Bernal ha sido el vencedor de la segunda edición del concurso fotográfico sobre piragüismo organizado por la web de Dani Durán.La foto ganadora fue precisamente la tomada desde la Remolina en la pasada edición del Sella que ha sido portada de nuestro primer número de la revista I love canoe.

Enhorabuena a Anselmo por la foto y por todas las que hace y a Dani Durán por su promoción del piragüismo.

hej

È stato un fine settimana piuttosto intenso: da giovedì a sabato sono stato impegnato a Milano alla prima edizione della JAX Italian Conference, e si è trattato di un esperienza assolutamente piacevole, soprattutto per l’atmosfera molto cordiale e per le interessanti discussione che abbiamo avuto modo di avere con gli altri speaker (italiani e stranieri) e con i partecipanti.

Vorrei quindi ringraziare Simone Longo, e tutto lo staff di Software & Support Media organizzatori dell’evento e tutti i partecipanti, in particolare i colleghi che hanno partecipato al workshop Domain Driven Design di sabato rendendolo una discussione interessante e stimolante. È stata una faticaccia, ma assolutamente anche un piacere

DDD Without any ORM tool, is it possible !!

Look at the thread http://tech.groups.yahoo.com/group/domaindrivendesign/message/16021

If you have done DDD without any ORM, your comments are valuable.
Please write your views.

Post yang lalu, kita telah bersetuju untuk memutus hubungan erat antar aggregate, komunikasi dilakukan dengan pub/sub. Mekanismenya, kita menggunakan Domain Event.

Menurut Udi, kunci dari Domain Event ada dalam kata “when”. Yang belum begitu jelas, siapa yang berhak meraise event? Agregate root, atau semua stakeholder agreegate?

Following on from his successful speaker spots at Skills Matter’s Progressive .NET tutorials earlier this year, the talented Mr David Laribee will be hosting a 2-day course at the new Skills Matter eXchange in December.

Over the course of two days we’ll engage in a diverse array of discussions, exercises, and summary talks aimed toward aspiring and existing technical leads, senior developers, coaches and architects. Participants will leave with actionable techniques and tools for leading their teams toward greater throughput and technical excellence.

In Mr Laribee’s own words “We need leaders that can get down and dirty with technology while mentoring and leading people while staying true to product vision. We need an embedded role in software teams like Toyota’s Chief Engineer: someone who brings skill and experience to bare in all areas of product development, product design, user experience, coaching, software craftsmanship, et. al. “

Places are filling up fast — so make sure you don’t miss out on yours: book before November 15 and pay only £550+VAT per delegate (RRP: £990).

For more information and to book visit the Skills Matter site and get your place.

Welly lebih suka jika per assembly, dengan demikian agreegate benar-benar terisolir. Oetawan keberatan, karena akan membengkakkan jumlah library. Tapi library bisa digabung dengan ILMerge.

Dalam DDD, Eric Evan mengijinkan adanya hubungan antara root dengan root atau entity dengan root, merujuk apa yang dilakukan Greg Young, aku dan Welly lebih suka untuk tidak ada reference sama sekali antar agreegate root. Hubungan antar agreegate diwakili oleh value object. Komunikasi antara agreegate dilakukan dengan messaging: pub/sub.

Ok. Mari kita diskusikan bagaimana seharusnya kita meletakkan kelas-kelas, perkakas, dan lain sebagainya agar memenuhi standart DDD dengan .Net.

Dalam salah satu sample DDD, orang membuat dalam Java, 1 paket 1 agreegate root yang berisi, entity, value object, domain event, dan interface dari repository, mungkin juga interface dari infrastruktur lainnya.

Lalu bagaimana dengan .net? Setujukah kalau kita buat setiap 1 agreegate root 1 namespace, yang berarti satu project. Isi dari project ini, interface (untuk tujuan mocking–agar mudah ditest?) terdiri dari interface infrastructur dan interface model, class (implementasi dari interface, yang harus didefinisikan sebagai internal), Factory (baik builder, abstrack, maupun method–lihat GOF).

Dengan demikian object-object tidak bisa dicreate dari luar, sehingga bisa diatur hanya lewat builder. Untuk menjaga agar object tidak bocor keluar, maka root tidak boleh mereturn apapun kecuali DTO. ? masih ada yang tertinggal?

Method harus eksplisit tidak boleh satu untuk semua message, consume misalnya. ?

Big Ball of Mud

Let’s start with my original example business, Acme Enterprise.  Acme wishes to build an ecommerce system to sell its products to its customers.  The developers at Acme start out by building a web application that customers can come to for placing orders, employees in the pricing department can update product prices, and employees in the inventory management department can maintain product SKUs and product levels.  As time goes on the pricing department wants to add new functionality to the system to maintain promotional pricing on products, discount pricing on products, etc.  The inventory department wants to add new functionality to the system to provide auto-replenishment on products, warehouse location of products, etc.  As the application grows into one monolithic system it can quickly become unmanageable in its current form, or as some call it, BBOM – Big Ball of Mud.  More importantly, the different departments within Acme define the term “Product” differently.  The sales department defines a “Product” as an item ordered by a customer and added to a shopping cart with a price and quantity ordered information attached to it.  The pricing department defines the “product” in terms of not only unit price, but promotional pricing, and marketing campaign pricing that is valid for a particular time period. Meanwhile the folks in inventory management define a “Product” in terms of Quantity on Hand, Warehouse Location, and Reorder Threshold Trigger.  As the system grows, so does the complexity and the size of our BBOM.

Bounded Contexts

This is where Domain Driven Design (DDD) can help with the design of our ecommerce system.  When we start to define the term “Product” with the people responsible for products in each of the departments within the company, we realize that they all care about this thing called a “Product” but they each talk about it in a different context.  This is where DDD introduces the idea of a Bounded Context.  Our system can be split into separate contexts each with its own explicit boundary.  So what we end up with in our system is a bunch of Bounded Contexts for each of the different contexts within the system: an inventory context, a pricing context, sales context, etc.  Each Bounded Context has its own model and ubiquitous language that defines the domain and entities like “Product” uniquely to its own definition.  The key phrase to our bounded context here is “explicit boundary”.  Each context provides a contract to the outside world to interact with and can be viewed as its own application within an application.  This can provide modularity to our overall system design.  One Bounded Context shares data with another Bounded Context via a Context Map.  A Context Map exposes a well defined contract interface that can be consumed.

Bounded Context as a Service

Now let’s take our DDD ecommerce system and apply SOA principles to it. Remember when I stated that a Bounded Context provides an explicit boundary?  One of the core tenets of SOA states that “Boundaries are explicit”.  I also stated that a Bounded Context can provide modularity within our system and that a context can be viewed as an application within an application.  Well another core tenet of SOA states that “Services are autonomous.” Hmm, so what else do bounded contexts and SOAs share in common?  A Bounded Context within our system communicates with another Bounded Context within our system via a context map that provides a contract interface to the outside world.  SOA; “Services share Schema and Contract, not Class”.  So when we compare the Bounded Context of our DDD and the Services of our SOA, there really isn’t a whole lot of difference between the two.  Maybe in an SOA we should call them “Bounded Services”?  SOA is about the separation of Bounded Contexts in our application into their own services so looser coupling can be achieved while providing a certain degree of service reuse within our enterprise.  Our context map or interface to the SOA service can be done via a web service, restful service, or WCF.  For example, in our DDD ecommerce application, if we wanted to replace the inventory context with a third party inventory management or ERP system like SAP, there may be a bit more work involved to decouple it from the old system and integrate the new SAP system.  With SOA, we have a lesser degree of coupling to deal with so integrating to the new inventory system will be easier.  Notice, I said “easier” not seamless.

EDA with NServiceBus

This brings me to Event-Driven Architecture (EDA), more specifically, EDA with NServiceBus.  As we’ve taken our initial BBOM ecommerce application and we introduced DDD principles to it and refactored our system, we began to decouple the system into different functional modules, or Bounded Context, within one application running on our web server.  Each department (inventory, pricing, sales), would access the same system to update their various domains of information.  As we moved to SOA, we took this one step farther by making these contexts autonomous services that can be distributed on different servers running within our enterprise, providing user access to a particular service to only the people in the department that need to update data within that service.  The problem with traditional SOA is it still gives us a certain level of coupling with our enterprise applications between services.  If the inventory service needs to inform the pricing service that a new SKU has been entered into the system, the inventory service must know that the pricing service exists within our enterprise.  Meaning, the inventory service must be programmed to make a service call to a service interface (web service, WCF, socket call, etc.) on the pricing service.  If we decide to use a different system in the future to do pricing, we need to update the inventory service to call the new service interfaces on the new pricing system.  This is where event messages and NServiceBus can help.  If we define a series of business events that describe important transactions within our enterprise, we can publish their event messages to a message bus.  Now instead of our services interacting directly and having to be aware of one another in the enterprise, each service only needs to know to publish event messages to the message bus, and only subscribe to event messages on the message bus that it cares about.  So in the case of our inventory service, and our pricing service, the inventory service can publish“New SKU” events and the pricing service and subscribe to “New SKU” events.  At no point does the inventory service need to know about the pricing service and conversely, the pricing service doesn’t need to know about the inventory service; now what “links” the two systems together are the “New SKU” events, and more importantly the data contained within.  In essence, the event messages and the service bus, in this case NServiceBus (but we could use others) become the “Context Map” defined back in our DDD application.  The event messages are our contracts and NServiceBus becomes our service transport layer to communicate between Bounded Contexts/Services with a higher level of decoupling between our services than we had with our traditional SOA.

In conclusion

            NServiceBus provides an easy to use API to the framework to work with so we can create an event message driven architecture.  Publishing event messages via NServiceBus will allow for a much more loose coupling design between the different Bounded Contexts or Services running in our enterprise.  While applications or services will always have a higher degree of coupling between their application layers, (UI, Business Layer, DAL, etc.), Event-Driven Architecture with NServiceBus can provide for a much lesser degree of coupling between the explicit boundaries of the services.

I tweeted this as a joke, but thought it deserved a brief post:
A senior manager in the company arbitrarily pulls a date out of the air (normally the Friday just before an important golfing holiday) for when he needs a report. This means that a load of developers need to jump though hoops to write a system to produce the report, whilst having to continually deal with requirement changes and middle management customers that can’t actually make a decision about anything. When the system is delivered a week late, the senior manager is already playing golf and doesn’t care anymore, so all the developers are sacked.

Esta semana fizemos mais uma grande melhoria na nossa camada de domínio, incorporando expressões lambda .Net nas nossas consultas e parâmetros de ordenação de repositórios. Retomando o post sobre a camada de domínio, os repositórios são utilizados para tirar a dependência da aplicação dos detalhes de persistência de objetos e para ser uma representação abstrata de uma coleção de entidades de domínio.

A idéia é que eles facilitem a busca de entidades específicas ou implementem métodos mais complexos para a execução de consultas. Como no nosso caso usamos o NHibernate para camada de persistência, nós temos duas opções de efetuar estas consultas, os Criterias (DetachedCriteria ou expressões ICriterion simples) ou o HQL, que é uma linguagem de consulta parecida com SQL só que composta pelas entidades de domínio.

Consultas HQL são baseadas em strings (ver exemplo abaixo do nosso sistema de ServiceDesk), o que é extremamente flexível porém não suporta intellisense nem é compilada (o que pode facilitar erros no caso de refactors). Mas, para o HQL não temos muita opção, a alternativa que seria usar o NH Linq ainda não é viável (pelo que eu tenho visto, ainda não suporta muitas coisas).

public int TotalInbox(User user) {
   const string hql =
       @"select count(*) from Incident i inner join i.Allocation a

         inner join a.SupportGroup s inner join s.Users u 

         inner join i.Company c
         where i.ClosedOn is null and a.SupportUser is null
         and i.State != isnull(c.WaitingUserConfirmationState,-1) 

         and i.State != isnull(c.WaitingUserInformationState, -1) 

         and u = ?";
   return (int) ExecuteScalar<long>(hql, user);
}

O uso de Criterias é mais simples e é indicado para consultas com restrições diretas na entidade base (ou nas que possuem relacionamento direto com a entidade base). Porém, nos criterias é necessário especificar o nome da propriedade como string. Novamente, sem intellisense e sujeito a problemas de refactor. Como o uso de Criterias é muito mais freqüente, nós automatizamos na nossa camada de domínio a geração de uma classe estática com todas as propriedades das entidades de domínio (usando arquivos .tt de um editor T4). Desta forma, temos intellisense e no caso de refactor que cause alguma quebra, teremos um erro de compilação (já que as classes são sempre regeradas). E, conforme falado no post da camada de domínio, construímos ainda uma fluent interface para facilitar a escrita. O exemplo abaixo mostra isto em funcionamento.

public long TotalClosed(User user) {
    return Query.Where(Restrictions.Eq(PN.User, user))

           .And(Restrictions.IsNotNull(PN.ClosedOn)).Count();
}

Esta solução estava bastante adequada até aparecer a alternativa de usarmos expressões lambda ao invés de gerar as classes estáticas. Existem algumas iniciativas já fazendo isto, como o projeto NHLambdaExtensions. Neste caso específico, porém, eles estão abordando isto como uma biblioteca à parte para a geração de Criterias do NH e não como algo integrado aos repositórios.

Felizmente, na nossa camada de domíno, os repositórios já são tipados para a entidade de domínio que eles representam. Desta foram, fica simples gerar as expressões. O exemplo abaixo mostra a mesma rotina acima, agora usando expressões lamdas.

public long TotalClosed(User user) {
    return 

      Query.Where(i => i.User == user && i.ClosedOn != null).Count();
}

Como pode ser visto, bem mais legível e intuitivo. E sem a necessidade de se usar classes estáticas de apoio! Ainda temos algum trabalho a ser feito, pois não é simples traduzir todos os tipos de lambda para restrições válidas. Mas para os casos mais simples como o acima, está já 100% funcionando.

Outro ponto interessante é que as funções que aceitam lambda podem ser expostos para camadas superiores de domínio, já que usar uma expressão lambda não causa dependência para a camada de persistência. Isto diminui de maneira significativa o próprio tamanho da implementação dos repositórios.

Finalmente, a utilização deste tipo de solução acaba sendo algo tão flexível que estamos passando a adotar em vários outros cenários. Na definição de classes de ordenação para consultas, na identificação de campos usados como atributos em formulários e controllers e assim por diante. Realmente algo muito simples que está aí desde o lançamento da versão 3.5 do .Net mas que demorou para  a “ficha cair” achar uma maneira legal de aplicar na nossa infraestrutura.

Quem quiser saber algum detalhe mais técnico da implementação basta me mandar um email. Até a próxima.

Tolle Sachen mit dem Weblog machen…….

Some class members will travel to faraway places in the United States and even Europe while others will spend most of their time closer to home, doing fun things with family members.

“I’m going to summer camp in the mountains,” writes Amber Smith. “My sister and brother are going, too. We’re going to sleep in log cabins like Abraham Lincoln.”

Looking for part 1? Click here.

Two Saturdays ago, M and I went down to Portland for our own Diners, Drive-Ins, and Dives road trip.  By noon on Saturday we had eaten breakfast at 2 different places: Pine State Biscuits and Arleta Library Bakery Cafe. With still most of the day ahead of us, we headed to downtown Portland where we checked out the PSU Farmer’s Market and the Saturday market.  As this is more about DDD than farms and markets, I’ll stick to writing about where we ate and save all that other stuff for another day. Yes?

Yes!

Ok, so after good times in Downtown Portland, we headed to Otto’s Sausage Kitchen and Meat Market on SE Woodstock for delicious hot dogs.

Tired from a long day and not really hungry (with having eaten 2 breakfasts, how could we be?), we decided to split a dog as we didn’t really want to leave Portland without trying this place out. And??  And we were both impressed by the texture and flavour of what we got.  Freshly grilled over charcoal just outside the shop, our hot dog was dense, beefy, and flavourful.  You know when hotdog companies advertise that their dogs are made of 100% beef with no filler?  Well, they’re lying because the hotdog we had at Otto’s tasted like what a hot dog made of 100% beef with no filler SHOULD taste like.   In addition to tasty dogs, Otto’s is a full-on deli and meat market with a great selection of cut meats, deli items, and a sandwich counter.  Looking for a drink?  They also have an array of wines and beers and refreshing colas. M and I wanted to get some meat and dogs to take home to Vancouver but with 6 hours of driving, one more stop left, and no refrigeration, we decided against it.

And with that, we headed out of Portland and drove towards Seattle for the last stop of our food tour: Slim’s Last Chance Chili Shack.

Located in the Georgetown District in what looked to us like an industrial area, Slim’s Last Chance Chili Shack is a restaurant/bar/music venue/hangout.  M and I arrived at around 8:30pm excited to try some chili.  As soon as we entered, we noticed that there was going to be a show that night and that we had to pay cover.  Not really wanting to pay cover just to eat chili, we contemplated going home empty stomached.  Fortunately, the guy at the door, a man with a nice, long, not quite ZZ Top-length beard, let us in without having to pay for cover (probably because he saw the look of disappointment in our faces, ha!).  We sat at the bar, ordered our chili and had a good look at the place.  Decorated with Mexican tin art, pistols, and a colourful stage, Slim’s is a pretty cool place that we wished we had more time to enjoy.

M ordered the Texas Red over mac and cheese while I ordered the Chili Verde plain. This was the first time we’ve had beanless chili and it was very good, unlike any other chili we’ve ever tried (not that we’ve tried a lot).  The Texas Red was meaty with a spicy-tangy kick while the Chili Verde had very tender meat and absolutely satisfying.  Both dishes were so good that M made his own beanless chili over mac and cheese days later.

And that’s it! After our chili dinner, we drove back home to Vancouver arriving at around 1am Sunday morning, exactly 24hrs from the time we left the night before.

Interested in reading Diners, Drive-ins, and Dives: Portland and Seattle, part 1? Click here!

]]> http://alanmacgowan.wordpress.com/2009/10/16/behavior-driven-development-bdd/ Fri, 16 Oct 2009 03:31:35 +0000 alanmacgowan http://alanmacgowan.wordpress.com/2009/10/16/behavior-driven-development-bdd/