core___java的博客

UML中定义了用例图、类图、时序图、协作图等九种。设计模式中经常会用到的是类图。类是面向对象系统组织结构的核心，类可以说是对一组具有相同属性、操作、关系和语义的对象的抽象。在UML中，类使用带有分隔线的矩形表示，它包含名称部分（Name）、属性部分（Attribute）和操作部分（Operation）。其中属性的表现形式是[可见性] 属性名:类型 [=默认值]。操作的表现形式是：[可见性] 名称（参数列表）[：返回类型]。详细见下图。1.类图基础属性+表示p...

一、前言上一篇文章 领域驱动之领域模型，简单的学一学 DDD 了解了一些 DDD 理论，然而 DDD 难点和精髓却是在其实战的落地上，如今的社会不缺乏理论依据和理论指导，但是实实在在的落地似乎成了永远无法落地的承诺。话不多说今天我们拿打车软件作为我们实战的载体，例如滴滴打车、美团打车、T3出行等等。全文思路先从功能分析，到 DDD 的战略设，再到 DDD 的战术设计，最后 基于现实业务的 DDD 实战落地。二、开始战斗2.1 功能分析滴滴打车、美团打车、T3出行这些打车软件都有三

一、开篇我们在学习新的技术或者解决某些业务和技术问题时，很多同学都会一股脑的钻进细节和思考如何快速解决，久而久之形成了点状的知识结构和认知体系。如同我经常在面试一些中高级程序员的时候，经常会问一个问题：java 的知识体系是什么/java 的组成是什么。也正如自己所预期的那样，经常有候选人不知所云，用我高中一位班主任的口头禅：茫茫然不知其所以然。于是我们得到一个结论：体系的思考和学习是如此的重要，以至于另当今浮躁的社会和风气让那些可以沉下来的程序员无形中少了很多竞争对手。二、回归主题我们回归本次

写在前面：要不要DDD​ 网上关于领域驱动的相关文章数不胜数，但是就跟我一个同事说的，具体落地的到底有多少呢？我们说领域驱动最核心的就是领域模型，一个稳定的领域模型胜过千军万马，然而在当下依然是互联网的时代，业务告诉发展的时期，一切的产品设计和技术都是服务于业务，然而有多少业务是随心所欲闭门造车临时方案的情况，我想程序员们应该是深有体会。于是带来一个问题，业务层面如此的不固定，我们如何跟业务通过领域建模来统一语言，更别说稳定我们的领域模型了（一段时间范围内的相对稳定）。同时在那些不懂技术的老板眼里，他们

作为官方认定的“农民工”，在受宠若惊之后唯有继续我们的学习之路。也想了一些时间，学什么呢？左思右想之后决定了回归本源，夯实我们的生存执法，首先要从内功修炼开始，内功心法开篇便是设计模式，话不多说让我们开始吧。代理的解释 暂时代人担任 某单位的负责职务。 代理人在代理权限范围内，以被代理人的名义同第三人独立进行民事法律行为，由此产生的法律后果直接归属于被代理人的法律制度。包括法定代理、委托代理和指定代理。 以上是官方解释，用语已经相当直白，就是代替别人做某些事件，而且是暂时代替并不