个人观点及总结
领域专家不一定是专家，不一定是技术人员，可以由技术，产品，商务、运营、业务经理等等角色组成
领域专家应该包括三种角色：
1、如果是现有系统，应该是对业务足够熟悉，理解业务模型内部通用语言，了解业务系统设计的详细的需求背景及以往历程；如果是新系统，应该了解产品愿景，清晰知道业务系统的业务功能及系统能力
2、了解业务后续发展规划，对行业发展现状及未来有足够洞察力，全局观认识业务形态，并能很好兑现产品的商业价值和品牌价值
3、熟悉领域建模，具备划分业务模型逻辑边界，建立限界上线文内部通用语言，抽象领域模型，并落地工程能力
DDD领域驱动设计概述 前言 领域驱动设计（Domain Driven Design，简称DDD）是一种软件开发方法论，旨在帮助开发人员更好地理解业务需求，将业务需
个人观点及总结 领域专家不一定是专家，不一定是技术人员，可以由技术，产品，商务、运营、业务经理等等角色组成 领域专家应该包括三种角色： > 1、如果是现有系统，应该是对业
‘领域驱动设计’估计大部分人看了并不太理解，‘领域’是指建立了领域模型，‘设计’是指程序实现也就是程序编码。 领域驱动设计可以理解为：严格按照模型来编写代码，能够使代码更好地
建立模型的可行方案： 1、与领域专业人员沟通，可通过边提问边回答的方式。 2，挖掘领域中的名词和流程。 3、尝试画图，通过图来走查各种场景。 4、相互学习，共同消除
> 最近在做一些微服务相关的设计，内容包括服务的划分，Restful API的设计等。其中比较棘手的就是Service的职责划分：如何抽象具有统一业务范畴的Model，使其模块
点击关注公众号，利用碎片时间学习![0d585d6a52aac94108f91bac86a26eb0.png][] 把服务对象（service）和资源库对象（reposito
基本概念： 领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tac
拼搏现实的明天。
骑猪看日落
向右看齐
不念不忘少年蓝@
还没有评论，来说两句吧...