{"id":10048,"date":"2023-12-12T11:10:40","date_gmt":"2023-12-12T14:10:40","guid":{"rendered":"https:\/\/elemarjr.com\/clube-de-estudos\/?post_type=artigos&p=10048"},"modified":"2023-12-26T09:54:30","modified_gmt":"2023-12-26T12:54:30","slug":"o-modelo-de-dominio-deve-definir-mensagens-para-usuarios","status":"publish","type":"artigos","link":"https:\/\/elemarjr.com\/clube-de-estudos\/artigos\/o-modelo-de-dominio-deve-definir-mensagens-para-usuarios\/","title":{"rendered":"O Modelo de Dom\u00ednio Deve Definir Mensagens para Usu\u00e1rios?"},"content":{"rendered":"\n

No universo do desenvolvimento de software, especialmente quando discutimos Domain-driven Design<\/em> (DDD), uma das quest\u00f5es que aparecem \u00e9: o modelo de dom\u00ednio deve incluir a responsabilidade de definir como as mensagens s\u00e3o apresentadas para o usu\u00e1rio? Esta quest\u00e3o \u00e9 mais profunda do que parece e toca na ess\u00eancia da arquitetura de software e do design centrado no dom\u00ednio.<\/p>\n\n\n\n

A Responsabilidade do Modelo de Dom\u00ednio<\/h2>\n\n\n\n

No Domain-driven Design<\/em>, o modelo de dom\u00ednio representa as regras de neg\u00f3cio e a l\u00f3gica fundamental do sistema que estamos construindo. Ele \u00e9 o cora\u00e7\u00e3o do neg\u00f3cio e deve ser preservado como tal. Mas considerem o seguinte cen\u00e1rio: uma viola\u00e7\u00e3o de regra de neg\u00f3cio ocorreu e uma mensagem de erro precisa ser comunicada. Onde e como essa defini\u00e7\u00e3o de mensagem deve ser feita?<\/p>\n\n\n\n

\u00c0 primeira vista, pode-se argumentar que o modelo de dom\u00ednio, sendo focado no neg\u00f3cio, n\u00e3o deve se preocupar com a interface do usu\u00e1rio (UI). Vamos ilustrar com um exemplo em C#:<\/p>\n\n\n\n

<\/circle><\/circle><\/circle><\/g><\/svg><\/span><\/path><\/path><\/svg><\/span>
public<\/span> <\/span>class<\/span> <\/span>Order<\/span><\/span>\n{<\/span><\/span>\n    <\/span>public<\/span> <\/span>void<\/span> <\/span>AddProduct<\/span>(<\/span>Product product<\/span>)<\/span><\/span>\n    <\/span>{<\/span><\/span>\n        <\/span>if<\/span> <\/span>(<\/span>product<\/span> <\/span>==<\/span> <\/span>null<\/span>)<\/span> <\/span><\/span>\n        <\/span>{<\/span><\/span>\n            <\/span>throw<\/span> <\/span>new<\/span> DomainException<\/span>(<\/span>"<\/span>Product cannot be null<\/span>"<\/span>)<\/span>;<\/span><\/span>\n        <\/span>}<\/span><\/span>\n<\/span>\n        <\/span>\/\/ Logic to add the product...<\/span><\/span>\n    <\/span>}<\/span><\/span>\n}<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
No exemplo acima, DomainException<\/code> \u00e9 uma exce\u00e7\u00e3o espec\u00edfica do dom\u00ednio que carrega a mensagem sobre o que deu errado. A camada de apresenta\u00e7\u00e3o, por outro lado, capturaria essa exce\u00e7\u00e3o e decidiria como apresent\u00e1-la:<\/p>\n\n\n\n
<\/circle><\/circle><\/circle><\/g><\/svg><\/span><\/path><\/path><\/svg><\/span>
try<\/span><\/span>\n{<\/span><\/span>\n    <\/span>order<\/span>.<\/span>AddProduct<\/span>(<\/span>null<\/span>)<\/span>;<\/span><\/span>\n}<\/span><\/span>\ncatch<\/span> <\/span>(<\/span>DomainException ex<\/span>)<\/span><\/span>\n{<\/span><\/span>\n    <\/span>userInterface<\/span>.<\/span>ShowError<\/span>(<\/span>ex<\/span>.<\/span>Message<\/span>)<\/span>;<\/span><\/span>\n}<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
Aqui, a responsabilidade de mostrar a mensagem ao usu\u00e1rio est\u00e1 na camada de apresenta\u00e7\u00e3o, que pode variar conforme o dispositivo ou contexto, mantendo o modelo de dom\u00ednio intocado.<\/p>\n\n\n\n
Interface de Usu\u00e1rio e Experi\u00eancia do Usu\u00e1rio<\/h2>\n\n\n\n
A experi\u00eancia do usu\u00e1rio (UX) \u00e9 moldada pela camada de apresenta\u00e7\u00e3o. Considere que um erro pode ser apresentado de maneira diferente num aplicativo web e num aplicativo m\u00f3vel. A camada de apresenta\u00e7\u00e3o deve ser adapt\u00e1vel para proporcionar a melhor experi\u00eancia poss\u00edvel, independentemente do ponto de contato com o usu\u00e1rio.<\/p>\n\n\n\n
Essa separa\u00e7\u00e3o de responsabilidades significa que, enquanto o modelo de dom\u00ednio prov\u00ea as regras e informa\u00e7\u00f5es necess\u00e1rias, a camada de apresenta\u00e7\u00e3o utiliza essas informa\u00e7\u00f5es para construir a UX.<\/p>\n\n\n\n
Flexibilidade e Manutenibilidade<\/h2>\n\n\n\n
A ades\u00e3o a DDD e a segrega\u00e7\u00e3o entre dom\u00ednio e apresenta\u00e7\u00e3o resultam em uma arquitetura mais f\u00e1cil de manter e evoluir. Altera\u00e7\u00f5es na forma como as informa\u00e7\u00f5es s\u00e3o apresentadas n\u00e3o afetam o n\u00facleo de neg\u00f3cio, permitindo que melhorias e ajustes sejam feitos com menos esfor\u00e7o e custo.<\/p>\n\n\n\n
Para aprofundar o entendimento sobre DDD e design de UX, recomendo explorar obras como “Domain-Driven Design: Tackling Complexity in the Heart of Software” de Eric Evans e “Don’t Make Me Think” de Steve Krug, que abordam, respectivamente, os conceitos de design centrado no dom\u00ednio e as pr\u00e1ticas recomendadas para a experi\u00eancia do usu\u00e1rio.<\/p>\n\n\n\n
Conclus\u00e3o<\/h2>\n\n\n\n
O modelo de dom\u00ednio em DDD deve focar em expressar as regras de neg\u00f3cio, enquanto a camada de apresenta\u00e7\u00e3o deve se responsabilizar pela experi\u00eancia do usu\u00e1rio. A comunica\u00e7\u00e3o entre essas camadas \u00e9 vital, mas cada uma possui suas responsabilidades espec\u00edficas. No design e desenvolvimento de software, \u00e9 crucial manter essa separa\u00e7\u00e3o para promover a flexibilidade, a manutenibilidade e, em \u00faltima an\u00e1lise, o sucesso do produto.<\/p>\n\n\n\n
Nos meus grupos de estudos e mentorias, estudamos esses conceitos detalhadamente e exploramos as melhores pr\u00e1ticas de DDD e UX para criar sistemas robustos e centrados no usu\u00e1rio.<\/p>\n\n\n\n
TL;DR<\/h2>\n\n\n\n
    \n
  1. O modelo de dom\u00ednio em DDD foca nas regras e l\u00f3gicas de neg\u00f3cio e n\u00e3o deve se preocupar com a forma como as mensagens s\u00e3o apresentadas aos usu\u00e1rios.<\/li>\n\n\n\n
  2. A experi\u00eancia do usu\u00e1rio \u00e9 responsabilidade da camada de apresenta\u00e7\u00e3o, que utiliza as informa\u00e7\u00f5es do modelo de dom\u00ednio para construir a interface de usu\u00e1rio.<\/li>\n\n\n\n
  3. Segregar a l\u00f3gica de neg\u00f3cio da experi\u00eancia do usu\u00e1rio aumenta a manutenibilidade e a adaptabilidade do software, permitindo evolu\u00e7\u00f5es mais \u00e1geis e custos reduzidos de manuten\u00e7\u00e3o.<\/li>\n<\/ol>\n","protected":false},"featured_media":10037,"parent":0,"template":"","cursos":[12],"class_list":["post-10048","artigos","type-artigos","status-publish","has-post-thumbnail","hentry","cursos-ddd-do-jeito-certo"],"acf":[],"_links":{"self":[{"href":"https:\/\/elemarjr.com\/clube-de-estudos\/wp-json\/wp\/v2\/artigos\/10048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/clube-de-estudos\/wp-json\/wp\/v2\/artigos"}],"about":[{"href":"https:\/\/elemarjr.com\/clube-de-estudos\/wp-json\/wp\/v2\/types\/artigos"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/clube-de-estudos\/wp-json\/wp\/v2\/media\/10037"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/clube-de-estudos\/wp-json\/wp\/v2\/media?parent=10048"}],"wp:term":[{"taxonomy":"cursos","embeddable":true,"href":"https:\/\/elemarjr.com\/clube-de-estudos\/wp-json\/wp\/v2\/cursos?post=10048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}