即使之前有过 DDD 结构设计的伤痛历经(发送者控制系统),其二是,假如真正 DDD 结构设计,须要耗费大量的天数和心力,可能将两天都在思索两个问题或者考量录于标识符的撰写,但最后也可能将没甚么推论或结果,
palio!怎样download专业课程
并且那个过程是很艰困和伤痛的,因此我而后就变懒了,懒的去思索工程项目所表现的销售业务,也不再考量怎样去结构设计应用领域数学模型,而已在考量怎样让架构用起来无形中,DDD.Sample 前两个应用应用领域的实际工程项目,我都是在健全那个架构,比如说 Repository 和 UnitOfWork 的结构设计之类,因此,有关应用领域数学模型的结构设计,是一大堆糖尿病数学模型。不过,而后应用应用领域的第二个工程项目,也是上两个前述工程项目,我觉得不能再这样下去了,即使没啥象征意义,架构两遍两遍的指涉,而 DDD 却和它没半块钱关系,因此,我就花了点天数去思索(而已单纯的思索):我做那个工程项目的核心理念销售业务是甚么?我该怎样提炼核心理念销售业务?提炼核心理念销售业务之后,其他的任何同时实现都是为核心理念销售业务服务的,因此,你能把那个核心理念销售业务看作应用领域数学模型。
有关第二个应用应用领域工程项目,前述上是他们Seiches的“提及我”控制系统,现在已经应用应用领域在新闻报道文章了,大家能去嘿嘿,类似于为博客的“提及我”,相对非常单纯的两个控制系统,你能在文章中@两个人,接着另两个人能拒绝接受通告,那那个控制系统的核心理念销售业务是甚么?其实是下面此时此刻,或者说你须要释放出来出一些内容,假如专家和开发者进行沟通交流那个控制系统的结构设计,那应用领域专家的论述是:你能在文章中@两个人,接着另两个人能拒绝接受通告,专家可能将要学标识符结构设计,他的那个论述是最间接和最精确的销售业务,因此,他们须要特别针对该文,再和专家研讨下所蕴含着的销售业务:
你能在文章中@两个人->@两个人->怎么能得到并证实那个“两个人”->@相匹配准则另两个人能拒绝接受通告->通告->通告所@的人
因此,@相匹配准则和通告所@的人是“提及我”控制系统的核心理念销售业务,确定好核心理念销售业务了,那就该具体的同时实现了,有关那个我没有深入细致的去考量,就间接放到了 Mention(提及)中,大体标识符:
namespace CNBlogs.Mention.Domain{ public class Mention : IAggregateRoot { private static readonly string SplitRegex =”::@,”; private static readonly Regex MentionsRegex = new Regex($”@([^{SplitRegex}]+)”, RegexOptions.Compiled); public int Id { get; set;} public string Content { get; set;} public int ContentId { get; set;} public AppType AppType { get; set;} …//释放出来 public async Task
看起来很单纯,是把两个方法放到了 Mention 中,但这单纯的操作却好像给 Mention 应用领域数学模型生命一样,不再那么糖尿病,对于复杂控制系统的销售业务变化,往往是核心理念销售业务的变化,其他的都是为核心理念销售业务服务的销售业务流程,并不能真正称为销售业务,比如说 Application 层的标识符,现在专家说@两个人的准则须要改变,或者通告准则须要变化,他们只须要修改 Mention 应用领域数学模型的标识符就行了,其他的标识符并不须要修改,这是 DDD 结构设计最浅显的体现。
大体贴下 Application 层的伪标识符:
namespace CNBlogs.Mention.Application.Services{ public class MentionService : IMentionService { private IMentionRepository mentionRepository; private IUnitOfWork unitOfWork; public MentionService(IUnitOfWork unitOfWork, IMentionRepository mentionRepository){ unitOfWork = unitOfWork; mentionRepository = mentionRepository;} public async Task Submit(string content ,int contentId, AppType appType){ var notifyMentions = new List(); var existingQuery = mentionRepository.Get(contentId, appType); var mention = new Domain.Mention(){ Content = content, ContentId = contentId, AppType = appType }; var userIds = await mention.Extract(); foreach (var userId in userIds){ var userQuery = existingQuery.Where(x => x.UserId == userId); if (await userQuery.AnyAsync()){ await userQuery.UpdateAsync(x => new Domain.Mention { Content = content, DateUpdated = DateTime.Now });} else { mention.UserId = userId; unitOfWork.RegisterNew(mention); notifyMentions.Add(mention);} } if (await unitOfWork.CommitAsync()){ foreach (var notifyMention in notifyMentions){ await notifyMention.Notify();} return new SubmitResult();} return new SubmitResult { IsSucceed = false };} }}
能看到,Submit 中的操作基本上都是工作流程,先抽取用户,再进行判断更新,接着进行持久化,最后进行通告,没有任何销售业务体现,因此,假如核心理念业务发生了变化,这部分的标识符并不须要随之改变。
怎样 DDD?
引自:《Implementing DDD Reading – Strategic Design》
怎样 DDD?其实答案都在下面的图中,图中的设计在《同时实现应用领域驱动力结构设计》书中,被定义为战略建模(Strategic Modeling),主要包含应用领域、核心理念域、子域、通用子域、支撑子域、限界上下文、协作上下文、上下文映射图之类概念,我之前的几篇《IDDD 同时实现应用领域驱动力结构设计》控制系统文章,也有过相关的介绍,说实话,我而已当时读过写过有些记忆,现在让我再说任何两个概念,基本上我说不上来,对于我个人来说,战略建模是一种宏观的建模方式,你须要站在高处去俯瞰整个控制系统,并须要释放出来出控制系统所包含的销售业务,并将它们一一划分,那个工作是非常难的,推荐几篇战略建模相关的文章:
初窥 Bounded Context怎样识别 Bounded Context应用领域驱动力结构设计实战–战略建模
除了战略建模,还有一种建模方式叫战术建模(Tactical Modeling),主要包含聚合(Aggregate)、实体(Entity)、值对象(Value Objects)、资源库(Repository)、应用领域服务(Domain Services)、应用领域事件(Domain Events)、模块(Modules)之类概念。
在《同时实现应用领域驱动力结构设计》书中,Scrum 团队(两个前述工程项目的开发团队)一开始是采用的战术建模,并且在开发的过程中,他们并不知道战略建模是甚么?最后导致了很多问题,书中有个节点就专门讲了“战略结构设计为甚么重要?”,但我个人觉得,战略建模的重要也而已相对而言,它在应对大型复杂性的销售业务控制系统结构设计中,能充分发挥它的特点,但特别针对一些相对单纯的控制系统,还不如间接进行战术建模,比如说下面说的“提及我”控制系统。
因此,目前来说,进行战术建模比较现实和有象征意义,但在进行战术建模之前,我觉得还有两个重要的工作,是和专家进行沟通交流控制系统销售业务,那个工作并不包含具体的战术建模该怎样结构设计,比如说聚合、实体啥的,和专家并不须要讨论这部分内容,而是控制系统所包含的销售业务,就像“提及我”控制系统中,我问我自己“我做那个工程项目的核心理念销售业务是甚么?”。
专家并不是两个职位,他能是精通销售业务的任何人。他们可能将了解更多的有关销售业务应用领域的背景知识,他们可能将是软件产品的结构设计者,甚至有可能将是销售员。
前述工程项目的课堂教学
好,概念说太多没甚么象征意义,前述应用应用领域才有价值,我现在在开发两个 JS 权限申请和审核控制系统,是他们Seiches里的 JS 权限申请,即使现在申请 JS 权限须要发邮件进行申请,对于用户申请和他们处理来说,都比较麻烦并且费天数,因此为了解决那个问题,他们想做把 JS 权限申请做成像申请博客一样,园友填写申请内容,接着他们进行后台审核,效率能提升很多,大概是这样的两个控制系统,真实的不能再真实了,毕竟园友和他们都会前述接触并使用,这也是两个相对较小的控制系统,他们就拿它来开刀,看看 DDD 的这把刀锋不锋利。
对于 JS 权限申请和审核控制系统来说,专家是谁?应该是园友和管理员,毕竟他们在使用那个控制系统,没有人比他们更了解其中的销售业务了,因此他们是那个控制系统的专家,须要强调的是,虽然有时候专家是开发者,但在一开始探讨销售业务控制系统的时候,一定不能牵扯到数据库和标识符的结构设计,他们应该忘掉数据库和标识符,而已单纯的站在专家的角度,去探讨和思索销售业务控制系统,那专家该怎样论述那个控制系统的销售业务呢?