<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Equilíbrio e Granularidade de Serviços (III)</title>
	<atom:link href="http://www.aqueleblogdesoa.com.br/2008/07/equilibrio-e-granularidade-de-servicos-iii/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.aqueleblogdesoa.com.br/2008/07/equilibrio-e-granularidade-de-servicos-iii/</link>
	<description>SOA? Veja bem...</description>
	<lastBuildDate>Fri, 10 Feb 2012 08:13:36 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Daniel Oshiro</title>
		<link>http://www.aqueleblogdesoa.com.br/2008/07/equilibrio-e-granularidade-de-servicos-iii/comment-page-1/#comment-12464</link>
		<dc:creator>Daniel Oshiro</dc:creator>
		<pubDate>Wed, 24 Aug 2011 15:19:51 +0000</pubDate>
		<guid isPermaLink="false">http://aqueleblogdesoa.wordpress.com/?p=232#comment-12464</guid>
		<description>Legal o post. Mas eu senti falta de ter um jeito de definir mesmo a ganularidade. Fiquei pensanso em como definir, e parece que essa granularidade não é definida, mas sim aparece naturalmente enquanto o arquiteto faz o design.

Um step-by-step para isso acontecer poderia ser algo do tipo:

- Baseado em um processo de negócio, definir as operações de cada passo do processo.

- Para cada operação, analisar se ela vai ser utilizada em mais de um passo do processo.
Se sim, pode pensar em criar um serviço com menor granularidade com essa operação.
Se não, pode criar um serviço com granularidade mais grossa que contenha esta operação.

- Feita esta análise, juntar as operações, considerando seus significados.
Ex.: Se houver as operações, enviarCorreio, receberCorreio, enviarFatura, listarEstoque,
com certeza vocês não juntaria enviarCorreio com enviarFatura. Não faria sentido.
Faria mais sentido juntar as operaçõs enviarCorreio e receberCorreio, dentro de um serviço chamado CorreioService

- Desta maneira, a granularidade iria aparecer naturalmente. Ao invés de precisar definir a granularidade antes,
ou tentar achar uma fórmula mágica para defini-la.

O que vc acha ?

Abraço.</description>
		<content:encoded><![CDATA[<p>Legal o post. Mas eu senti falta de ter um jeito de definir mesmo a ganularidade. Fiquei pensanso em como definir, e parece que essa granularidade não é definida, mas sim aparece naturalmente enquanto o arquiteto faz o design.</p>
<p>Um step-by-step para isso acontecer poderia ser algo do tipo:</p>
<p>- Baseado em um processo de negócio, definir as operações de cada passo do processo.</p>
<p>- Para cada operação, analisar se ela vai ser utilizada em mais de um passo do processo.<br />
Se sim, pode pensar em criar um serviço com menor granularidade com essa operação.<br />
Se não, pode criar um serviço com granularidade mais grossa que contenha esta operação.</p>
<p>- Feita esta análise, juntar as operações, considerando seus significados.<br />
Ex.: Se houver as operações, enviarCorreio, receberCorreio, enviarFatura, listarEstoque,<br />
com certeza vocês não juntaria enviarCorreio com enviarFatura. Não faria sentido.<br />
Faria mais sentido juntar as operaçõs enviarCorreio e receberCorreio, dentro de um serviço chamado CorreioService</p>
<p>- Desta maneira, a granularidade iria aparecer naturalmente. Ao invés de precisar definir a granularidade antes,<br />
ou tentar achar uma fórmula mágica para defini-la.</p>
<p>O que vc acha ?</p>
<p>Abraço.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

